idnits 2.17.1
draft-chung-dtn-extension-prophet-icn-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (October 28, 2020) is 1276 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC2119' is mentioned on line 109, but not defined
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Delay-Tolerant Networking Y. W. Chung
2 Internet-Draft M. W. Kang
3 Intended status: Informational Y. Kim
4 Expires: April 27, 2021 Soongsil University
5 October 28, 2020
7 Extension of Probabilistic Routing Protocol using History of
8 Encounters and Transitivity for Information Centric Network
9 draft-chung-dtn-extension-prophet-icn-06.txt
11 Abstract
13 This document proposes extension of probabilistic routing protocol
14 using history of encounters and transitivity (PRoPHET) for
15 information centric network.
17 Status of This memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six
28 months and may be updated, replaced, or obsoleted by other documents
29 at any time. It is inappropriate to use Internet-Drafts as
30 reference material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on April 27, 2021.
34 Copyright Notice
36 Copyright (c) 2020 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with
44 respect to this document. Code Components extracted from this
45 document must include Simplified BSD License text as described in
46 Section 4.e of the Trust Legal Provisions and are provided without
47 warranty as described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction ................................................. 2
52 2. Conventions and Terminology .................................. 3
53 2.1. Conventions ............................................. 3
54 2.2. Terminology ............................................. 3
55 3. Forwarding of Interest and Data for ICN ...................... 3
56 3.1. Delivery predictability of PRoPHET ...................... 3
57 3.2. Extension for Interest forwarding ....................... 4
58 3.3. Extension for Data forwarding ........................... 4
59 3.4. Extension for caching ................................... 5
60 3.5. Operation of the proposed extension ..................... 7
61 3.6. Extension for overload control ......................... 13
62 3.7. Overload control based on context information .......... 17
63 3.8. Extension for forwarding priority ...................... 18
64 4. Security Considerations ..................................... 19
65 5. IANA Considerations ......................................... 19
66 6. References .................................................. 19
67 6.1. Normative References ................................... 19
68 6.2. Informative References ................................. 19
70 1. Introduction
72 In Information centric network (ICN), a node requests Data by
73 sending Interest packet and this Interest packet is forwarded
74 through ICN routers. A router with the requested Data replies to the
75 Interest to the requester and the Interest is delivered through a
76 reverse path of the forwarded Interest. ICN router manages content
77 store (CS), pending interest table (PIT), and forwarding information
78 base (FIB) [George2014]. In CS, cached data is stored for future use.
79 In PIT, the information of Interest, the incoming and outgoing faces
80 of the Interest are stored, and this information is used to deliver
81 Data to the requester using the reverse path of forwarded Interest.
82 FIB is used to forward Interest to appropriate faces.
84 ICN is considered important for communication of urgent messages in
85 disaster situations [Edo2014]. In disaster situations, communication
86 infrastructure is destroyed and networks are fragmented. In
87 fragmented networks where connectivity between the nodes at
88 different fragmented networks is not possible, opportunistic network
89 such as delay tolerant networks (DTN) can be used to deliver
90 messages. In DTN, a message is delivered to a destination node via
91 opportunistic contacts between intermediate nodes in a store-carry-
92 forward way.
94 Since forwarding of Interest and Data should be carried out
95 opportunistically using DTN in fragmented networks, forwarding
96 schemes of Interest and Data in connected ICN networks should be
97 extended to accommodate the disruptive characteristics of DTN. In
98 this draft, we consider probabilistic routing protocol using history
99 of encounters and transitivity (PRoPHET)[RFC6693] for extension.
100 Then, we propose forwarding schemes for Interest and Data of ICN.
102 2. Conventions and Terminology
104 2.1. Conventions
106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
108 document are to be interpreted as described in RFC 2119 [RFC2119].
110 2.2. Terminology
112 TBD
114 3. Forwarding of Interest and Data for ICN
116 3.1. Delivery predictability of PRoPHET
118 In PRoPHET, delivery predictability is defined between any two nodes.
119 The delivery predictability between node A and node B i.e., P(A,B),
120 increases whenever node A and node B contact as follows:
122 P(A,B)=P(A,B)_old+(1-delta-P(A,B)_old)*P_encounter,(1)
124 where delta sets an upper bound for P(A,B) and P_encounter is a
125 scaling factor to control the rate of increase [RFC6693].
127 Also, it decreases as time elapses since the last contact as
128 follows:
130 P(A,B)=P(A,B)_old*gamma^K,(2)
132 where 0<=gamma<=1 is an aging constant and K is the elapsed time.
134 Finally, the delivery predictability has a transitive property i.e.,
135 if node A and B encounter frequently, and node B and node C
136 encounter frequently, then node A probably encounters node C as
137 follows:
139 P(A,C)=MAX(P(A,C)_old,P(A,B)*P(B,C)*beta),(3)
141 3.2. Extension for Interest forwarding
143 Conventional DTN routing protocol is based on push model and the
144 destination of a message is a specific node. However, pull model is
145 used in ICN and Interest is forwarded based on content name, rather
146 than node ID. In order to forward Interest to appropriate nodes
147 which have the requested Data in its CS, the delivery predictability
148 of a node A for the Interest i corresponding to the requested Data
149 is defined as P(A,N(d_i)), similar to Eq. (1) as follows:
151 P(A,N(d_i))
153 =P(A,N(d_i))_old+(1-delta-P(A,N(d_i)_old)*P_encounter,(4)
155 where N(d_i) represents a set of nodes with the Data corresponding
156 to Interest i in its CS.
158 In Eq. (4), P(A,N(d_i)) increases whenever node A contacts another
159 node which has d_i in its CS, where the number of nodes having Data
160 d_i is generally larger than 1, since d_i can be cached in multiple
161 nodes by adopting the ICN approach. Similar to Eq. (2), the delivery
162 predictability of a node to a node set N(d_i) decreases as time
163 elapses since the last contact. We note that if node A has Data d_i,
164 P(A,N(d_i))=1.
166 When node A and node B contact, Interest i stored in node A is
167 forwarded to node B, if P(A,N(d_i)) < P(B,N(d_i)), since node B is a
168 more probable node to deliver Interest i to a node having d_i than
169 node A. In this case, the information of requester nodes for
170 Interest i is also delivered to node B. The information of requester
171 nodes for the same Interest i stored in both node A and node B is
172 shared, irrespective of the comparison of delivery predictabilities.
173 For example, if node A has Interest i with requester R1 and if node
174 B has Interest i with requester R2, both node A and node B have
175 information of requesters R1 and R2 for Interest i after contact.
177 3.3. Extension for Data forwarding
179 For the delivery of Data in DTN, there is no known reverse path like
180 the one using PIT in ICN. Therefore, Data also should be delivered
181 using DTN routing protocol, too. In the proposed extension, the
182 information of requesters for the considered Data is used to forward
183 the Data. If the number of requesters for the Data corresponding to
184 Interest i is only one, the forwarding scheme of conventional
185 PRoPHET can be applied directly since the destination of the Data is
186 a requester node and forwarding is carried out based on node ID.
187 That is, if P(B,R(d_i)) is larger than P(A,R(d_i)), the Data d_i is
188 forwarded to node B, where R(d_i) is defined as the requester node
189 for the Data corresponding to Interest i.
191 If there are multiple requesters for the Data corresponding to
192 Interest i, current forwarding scheme of PRoPHET should be extended,
193 too, based on the delivery predictability relationship of two
194 contact nodes for each requester. In this draft, three forwarding
195 schemes for multiple requesters are presented in as examples. If
196 node A and B contact and node A has Data with multiple requesters,
197 the Data can be forwarded to node B if any of the following
198 condition is met depending on the selected policy:
200 1) if the delivery predictability between node B and a requester is
201 larger than that between node A and the corresponding requester for
202 any requester,
204 2) if the delivery predictability between node B and a requester is
205 larger than that between node A and the corresponding requester for
206 all requesters,
208 3) if the average of the delivery predictabilities of node B and
209 requesters are larger than that between node A and the corresponding
210 requesters.
212 For example, if node A has Data d_i with requesters R1 and R2 and if
213 node B does not have Data d_i already when node A and node B contact,
214 Data d_i in node A will be forwarded to node B depending on a Data
215 forwarding policy as follows:
217 1) if P(A,R1(d_i))
|
336 +------------------------------------------------------------------+
337 Fig 1. Interest Forwarding Procedure (at time t)
339 Each node has a table for delivery predictability to a set of nodes
340 with Data corresponding to Interest in each node, as shown in Tables
341 1 and 2.
343 Table 1. Delivery predictability to a set of nodes with Data
344 corresponding to Interest in node A(at time t)
345 +==============================+
346 | Node | Delivery |
347 | set | Predictability |
348 +========+=====================+
349 | N(d 1) | 0.5 |
350 +--------+---------------------+
351 | N(d_2) | 0.6 |
352 +--------+---------------------+
353 | N(d_4) | 0.8 |
354 +==============================+
356 Table 2. Delivery predictability to a set of nodes with Data
357 corresponding to Interest in node B(at time t)
358 +==============================+
359 | Node | Delivery |
360 | set | Predictability |
361 +========+=====================+
362 | N(d_1) | 0.3 |
363 +--------+---------------------+
364 | N(d_2) | 0.7 |
365 +==============================+
367 After the contact of node A and node B, the requester information
368 for the same Data ID in Interest table is shared and thus requesters
369 R1 and R3 are stored in both node A and node B. Since the delivery
370 predictability of N(d_2) of node B is higher than that of node A,
371 requester information R2 is forwarded to node B.
373 Since node A contacts with node B which has Data d_3 in its cache,
374 delivery predictability of node A is updated, as shown in Table 3.
375 Since node B does not have delivery predictability to a node set
376 N(d_4) before contact, the delivery predictability of node B to a
377 node set is updated using transitivity property.
379 +------------------------------------------------------------------+
380 | +============================+ +============================+ |
381 | | Interest List in Node A | | Interest List in Node B | |
382 | +============================+ +============================+ |
383 | | ID | Data ID | Requester | | ID | Data ID | Requester | |
384 | +======+=========+===========+ +======+=========+===========+ |
385 | | i_1 | d_1 | R1, R3 | | i_3 | d_1 | R1, R3 | |
386 | +------+---------+-----------+ +------+---------+-----------+ |
387 | | i_2 | d_2 | R2 | | i_2 | d_2 | R2 | |
388 | +------+---------+-----------+ +============================+ |
389 | | i_4 | d_4 | R1 | +============================+ |
390 | +============================+ | Data List in B | |
391 | +============================+ |
392 | | ID | Requester | |
393 | +======+=====================+ |
394 | | d_3 | R4 | |
395 | +============================+ |
396 | ___ ___ |
397 | / \ / \ |
398 | ( A ) ( B ) |
399 | \___/ \___/ |
400 | |
401 | |
402 +------------------------------------------------------------------+
403 Fig 2. Interest Forwarding Procedure (at time t+dt)
405 Table 3. Delivery predictability to a set of nodes with Data
406 corresponding to Interest in node A(at time t+dt)
407 +==============================+
408 | Node | Delivery |
409 | set | Predictability |
410 +========+=====================+
411 | N(d_1) | 0.5 |
412 +--------+---------------------+
413 | N(d_2) | 0.6 |
414 +--------+---------------------+
415 | N(d_4) | 0.8 |
416 +--------+---------------------|
417 | N(d_3) | 0.5 |
418 +==============================+
420 Table 4. Delivery predictability to a set of nodes with Data
421 corresponding to Interest in node B(at time t+dt)
422 +==============================+
423 | Node | Delivery |
424 | set | Predictability |
425 +========+=====================+
426 | N(d_1) | 0.3 |
427 +--------+---------------------+
428 | N(d_2) | 0.7 |
429 +--------+---------------------+
430 | N(d_4) | 0.36 |
431 +==============================+
433 For Data forwarding, node A checks Data list. If node A has only one
434 requester information for the considered Data, node A forwards Data
435 d_i, which corresponds to Interest i, if node B does not have the
436 Data and P(B,R(d_i)) is larger than P(A,R(d_i)). If node A has
437 multiple requesters information for the considered Data, Data can be
438 forwarded to node B if any of forwarding condition for multiple
439 requesters defined in this draft is met, as proposed in Eqns. (4)-
440 (6). Information on requesters is delivered if Data is forwarded. If
441 both node A and node B have the same Data, the information of
442 requesters is shared between node A and node B after the contact.
444 Figures 3 and 4 show an example of the proposed Data forwarding
445 procedure. Each node has a Data list table, where the information of
446 Data and requester who requested the Data is stored.
448 +------------------------------------------------------------------+
449 | +============================+ +============================+ |
450 | | Data List in Node C | | Data List in Node D | |
451 | +============================+ +============================+ |
452 | | ID | Requester | | ID | Requester | |
453 | +======+=====================+ +======+=====================+ |
454 | | d_1 | R1, R3 | | d_2 | R4 | |
455 | +------+---------------------+ +============================+ |
456 | | d_2 | R2 | |
457 | +============================+ |
458 | ___ ___ |
459 | / \/ \ |
460 | ( C () D ) |
461 | \___/\___/ |
462 | |
463 | |
464 +------------------------------------------------------------------+
465 Fig 3. Data Forwarding Procedure (at time t)
467 Table 5 and Table 6 show delivery predictability to requester node
468 for corresponding data in each node.
470 Table 5. Delivery predictability to requester node for corresponding
471 Data in node C (at time t)
472 +==============================+
473 | Node | Delivery |
474 | ID | Predictability |
475 +========+=====================+
476 | R1 | 0.9 |
477 +--------+---------------------+
478 | R2 | 0.6 |
479 +--------+---------------------+
480 | R3 | 0.2 |
481 +--------+---------------------+
482 | R4 | 0.7 |
483 +==============================+
485 Table 6. Delivery predictability to requester node for corresponding
486 Data in node D (at time t)
487 +==============================+
488 | Node | Delivery |
489 | ID | Predictability |
490 +========+=====================+
491 | R1 | 0.7 |
492 +--------+---------------------+
493 | R2 | 0.7 |
494 +--------+---------------------+
495 | R3 | 0.6 |
496 +--------+---------------------+
497 | R4 | 0.9 |
498 +==============================+
500 As shown in Figure 4, requester information is shared between two
501 nodes. Thus requester information for Data d_2 is shared as R2 and
502 R4 and the requester information for Data d_1 of node A is
503 transferred to node B.
505 +------------------------------------------------------------------+
506 | +============================+ +============================+ |
507 | | Data List in Node C | | Data List in Node D | |
508 | +============================+ +============================+ |
509 | | ID | Requester | | ID | Requester | |
510 | +======+=====================+ +======+=====================+ |
511 | | d_1 | R1, R3 | | d_2 | R4, R2 | |
512 | +------+---------------------+ +------+---------------------+ |
513 | | d_2 | R2, R4 | | d_1 | R1, R3 | |
514 | +============================+ +============================+ |
515 | ___ ___ |
516 | / \ / \ |
517 | ( C ) ( D ) |
518 | \___/ \___/ |
519 | |
520 | |
521 +------------------------------------------------------------------+
522 Fig 4. Data Forwarding Procedure (at time t+dt)
524 Table 7 and Table 8 show delivery predictability to requester node
525 for corresponding data in node A and node B, respectively after the
526 contact, where the delivery predictability is updated.
528 Table 7. Delivery Predictability to requester node for corresponding
529 data in node C (at time t+dt)
530 +==============================+
531 | Node | Delivery |
532 | ID | Predictability |
533 +========+=====================+
534 | R1 | 0.9 |
535 +--------+---------------------+
536 | R2 | 0.6 |
537 +--------+---------------------+
538 | R3 | 0.27 |
539 +--------+---------------------+
540 | R4 | 0.7 |
541 +--------+---------------------+
542 | D | 0.5 |
543 +==============================+
545 Table 8. Delivery Predictability to requester node for corresponding
546 data in node D (at time t+dt)
547 +==============================+
548 | Node | Delivery |
549 | ID | Predictability |
550 +========+=====================+
551 | R1 | 0.7 |
552 +--------+---------------------+
553 | R2 | 0.7 |
554 +--------+---------------------+
555 | R3 | 0.6 |
556 +--------+---------------------+
557 | R4 | 0.9 |
558 +--------+---------------------+
559 | C | 0.5 |
560 +==============================+
562 3.6. Extension for overload control
564 In the proposed forwarding scheme, a requester node which issues an
565 Interest message does not know whether the Interest message has been
566 delivered to a node which has the requested Data until it receives a
567 requested Data. Therefore, unnecessary Interest messages may be
568 forwarded further even though it has been successfully delivered to
569 a node which has the requested Data already. Also, unnecessary Data
570 may be forwarded further even though it has been delivered to a
571 requester node already. Therefore, it is necessary to limit this
572 unnecessary overload of Interest and Data efficiently. In this
573 draft, we propose an extension for overload control, which is
574 basically based on the schemes proposed in the work in [Hass2006].
576 In the proposed overload control, we manage delivered Interest and
577 Data list in the pending anti-Interest and Data (PAID) table. If
578 node A forwards an Interest message i_1 to a node B which has the
579 requested Data d_1, we can apply one of the following three schemes
580 to limit the forwarding of the satisfied Interest message
581 efficiently as follows:
583 1) Scheme A: the node A removes the delivered Interest i_1 from its
584 Interest list and sets anti-Interest flag for the Interest message
585 i_1 in PAID table. Then, node A does not accept the i_1 again.
587 2) Scheme B: the node A removes the delivered Interest i_1 from its
588 Interest list and sets anti-Interest flag for the Interest
589 message i_1 in PAID table, and does not accept the i_1 again.
590 Further, if node A contacts another node C which has the same
591 Interest i_1, it shares anti-Interest flag with node C. Then, node
592 C removes the Interest i_1 from the Interest list and sets anti-
593 Interest flag for the Interest message i_1 in PAID table. The node
594 C does not accept the i_1 again.
596 3) Scheme C: the node A removes the delivered Interest i_1 from its
597 Interest list and sets anti-Interest flag for the Interest message
598 i_1 in PAID table, and does not accept the i_1 again. Further, if
599 node A contacts any node, it shares anti-Interest flag with the
600 contact node. If the contact node has the Interest i_1 already, it
601 removes the Interest i_1 from the Interest list and sets anti-
602 Interest flag for the Interest message i_1 in PAID table, and does
603 not accept the Interest i_1 again. Otherwise, it just sets anti-
604 Interest flag for the Interest message i_1 in PAID table and does
605 not accept the i_1 again.
607 +------------------------------------------------------------------+
608 | +============================+ +============================+ |
609 | | Interest List in Node A | | Interest List in Node C | |
610 | +============================+ +============================+ |
611 | | ID | Data ID | Requester | | ID | Data ID | Requester | |
612 | +======+=========+===========+ +======+=========+===========+ |
613 | | i_1 | d_1 | R1 | | i_3 | d_1 | R3 | |
614 | +============================+ +============================+ |
615 | +============================+ +============================+ |
616 | | PAID table in Node A | | PAID table in Node C | |
617 | +============================+ +============================+ |
618 | |Data ID| Requester ID| Flag | |Data ID| Requester ID| Flag | |
619 | +============================+ +============================+ |
620 | | d_1 | R1 | 0 | | d_1 | R1 | 1 | |
621 | +============================+ + +-------------+------+ |
622 | | | R3 | 0 | |
623 | +============================+ |
624 | ___ ___ |
625 | / \ / \ |
626 | ( A ) ( C ) |
627 | \___/ \___/ |
628 | |
629 | |
630 +------------------------------------------------------------------+
631 Fig 5. Overload control for Interest (at time t)
633 +------------------------------------------------------------------+
634 | +============================+ +============================+ |
635 | | Interest List in Node A | | Interest List in Node C | |
636 | +============================+ +============================+ |
637 | | ID | Data ID | Requester | | ID | Data ID | Requester | |
638 | +======+=========+===========+ +======+=========+===========+ |
639 | | i_1 | d_1 | R3 | | i_3 | d_1 | R3 | |
640 | +============================+ +============================+ |
641 | +============================+ +============================+ |
642 | | PAID table in Node A | | PAID table in Node C | |
643 | +============================+ +============================+ |
644 | |Data ID| Requester ID| Flag | |Data ID| Requester ID| Flag | |
645 | +============================+ +============================+ |
646 | | d_1 | R1 | 1 | | d_1 | R1 | 1 | |
647 | + +-------------+------+ + +-------------+------+ |
648 | | | R3 | 0 | | | R3 | 0 | |
649 | +============================+ +============================+ |
650 | ___ ___ |
651 | / \ / \ |
652 | ( A ) ( C ) |
653 | \___/ \___/ |
654 | |
655 | |
656 +------------------------------------------------------------------+
657 Fig 6. Overload control for Interest (at time t+dt)
659 Similar approaches can be applied to delivered Data, too. If Data
660 d_2 is delivered to a node E from a node D, which requested the Data
661 d_2 before, we can apply one of the following three schemes to limit
662 the forwarding of the delivered Data efficiently as follows:
664 1) Scheme D: the node D removes the delivered Data d_2 from its Data
665 list and sets anti-Data flag for the Data d_2 in PAID table. Then,
666 node D does not accept the d_2 again.
668 2) Scheme E: the node D removes the delivered Data d_2 from its Data
669 list and sets anti-Data flag for the Data d_2 in PAID table, and
670 does not accept the d_2 again. Further, if node D contacts another
671 node F which has the same Data d_2, it shares anti-Data flag with
672 node F. Then, node F removes the Data d_2 from the Data list and
673 sets anti-Data flag for the Data d_2 in PAID table. The node F
674 does not accept the d_2 again.
676 3) Scheme F: the node D removes the delivered Data d_2 from its Data
677 list and sets anti-Data flag for the Data d_2 in PAID table, and
678 does not accept the d_2 again. Further, if node D contacts any
679 node, it shares anti-Data flag with the contact node. If the
680 contact node has the Data d_2 already, it removes the Data d_2
681 from Data list and sets anti-Data flag for the Data d_2 in PAID
682 table, and does not accept the Data d_2 again. Otherwise, it just
683 sets anti-Data flag for the Data d_2 in PAID table and does not
684 accept the d_2 again.
686 +------------------------------------------------------------------+
687 | +============================+ +============================+ |
688 | | Data List in Node D | | Data List in Node F | |
689 | +============================+ +============================+ |
690 | | ID | Requester | | ID | Requester | |
691 | +======+=====================+ +======+=====================+ |
692 | | | | | d_2 | D | |
693 | +------+---------------------+ +============================+ |
694 | +============================+ +============================+ |
695 | | PAID table in Node D | | PAID table in Node F | |
696 | +============================+ +============================+ |
697 | |Data ID| Requester ID| Flag | |Data ID| Requester ID| Flag | |
698 | +============================+ +============================+ |
699 | | d_2 | D | 0 | | d_2 | D | 0 | |
700 | +============================+ + +-------------+------+ |
701 | | | R4 | 1 | |
702 | +============================+ |
703 | ___ ___ |
704 | / \ / \ |
705 | ( D ) ( F ) |
706 | \___/ \___/ |
707 | |
708 | |
709 +------------------------------------------------------------------+
710 Fig 7. Overload control for Data (at time t)
712 +------------------------------------------------------------------+
713 | +============================+ +============================+ |
714 | | Data List in Node D | | Data List in Node F | |
715 | +============================+ +============================+ |
716 | | ID | Requester | | ID | Requester | |
717 | +======+=====================+ +======+=====================+ |
718 | | | | | | | |
719 | +------+---------------------+ +============================+ |
720 | +============================+ +============================+ |
721 | | PAID table in Node D | | PAID table in Node F | |
722 | +============================+ +============================+ |
723 | |Data ID| Requester ID| Flag | |Data ID| Requester ID| Flag | |
724 | +============================+ +============================+ |
725 | | d_2 | D | 1 | | d_2 | D | 1 | |
726 | + +-------------+------+ + +-------------+------+ |
727 | | | R4 | 1 | | | R4 | 1 | |
728 | +============================+ +============================+ |
729 | ___ ___ |
730 | / \ / \ |
731 | ( D ) ( F ) |
732 | \___/ \___/ |
733 | |
734 | |
735 +------------------------------------------------------------------+
736 Fig 8. Overload control for Data (at time t+dt)
738 3.7. Overload control based on context information
740 The overload control schemes in Section 3.6 can be applied
741 dynamically, depending on the context information of Interest and
742 Data, since forwarding of Interest and Data should be treated
743 efficiently by considering context information. In the proposed
744 scheme, a non-overload control scheme is basically applied and if a
745 condition is met, overload control scheme proposed in Section 3.6 is
746 applied. Although numerous context information can be used, we
747 consider the number of hop counts, TTL, and the number of requester
748 nodes as examples as follows:
750 1) Number of hop counts: If the number of hop counts of Interest and
751 Data are not larger than threshold values, an overload control
752 scheme is not applied. Otherwise, an overload control scheme is
753 applied. The threshold value of Interest and Data can be defined
754 differently depending on the urgency of the Interest and Data.
756 2) TTL: If the TTL values of Interest and Data are not lager than
757 threshold values, an overload control scheme is not applied.
758 Otherwise, an overload control scheme is applied. This is because
759 if TTL of Interest and Data is larger, it means that it has been
760 forwarded more, and thus overload control scheme is needed to
761 avoid unnecessary forwarding.
763 3) Number of requester nodes: If the number of requester nodes of
764 Interest and Data are not larger than threshold values, an
765 overload control scheme is not applied. Otherwise, an overload
766 control scheme is applied. This is because if the number of
767 request nodes is smaller, more message dissemination is favorable
768 and thus, overload control scheme should not be applied.
770 3.8. Extension for forwarding priority
772 In PRoPHET protocol, if there are multiple messages to be forwarded
773 to a contact node, the messages are sorted based on the delivery
774 predictability of the contact node to the destination node of those
775 messages, and messages are forwarded in descending order of delivery
776 predictability of a contact node to the destination nodes. In ICN,
777 there may be multiple requester nodes for a requested Data, and thus,
778 Interest should be forwarded in descending order of delivery
779 predictability of a contact node B to the set of nodes with the Data
780 d_i corresponding to the Interest i, i.e., P(B,N(d_i)).
782 Also, since the number of requesters for Interest i, i.e., NR(i),
783 may be different for each Interest i, this information can be used
784 for determining forwarding priority. In this case, it is reasonable
785 to assume that Interest with more number of requesters has a higher
786 forwarding priority.
788 Since Interest may have different priority depending on the urgency
789 of the Interest, urgency priority can be defined and it can be used
790 for determining forwarding priority, too. For example, Interest
791 requesting rescue in disaster environment may have higher priority
792 than general content request. Urgency priority of Interest i, i.e.,
793 UP(i), can be defined for each Interest request appropriately with
794 values from 0 to 1, depending on the urgency of the Interest, where
795 higher value has higher urgency priority. It is reasonable to assume
796 that Interest with higher Interest priority has a higher forwarding
797 priority.
799 The above mentioned delivery predictability of a contact node to the
800 set of nodes with the requested Data for Interest, the number of
801 requesters for Interest, and the urgency priority can be used
802 separately for determining forwarding priority, depending on the
803 policy. Also, they can be used together by combining them
804 appropriately. For example, forwarding priority for Interest i,
805 FP(i) to a contact node B can be defined as follows:
807 FP(i)=P(B,N(d_i))*(NR(i)/NR_threshold)*UP(i),(10)
809 where NR_thereshold is an adjustment constant to control the effect
810 of NR(i) appropriately, compared to P(B,N(d_i)) and UP(i), which
811 have values between 0 and 1.
813 4. Security Considerations
815 TBD
817 5. IANA Considerations
819 TBD
821 6. References
823 6.1. Normative References
825 [RFC6693] Lindgren, A., Doria, A., Davies, E., Grasic, S,
826 "Probabilistic routing protocol for intermittently
827 connected networks", RFC 6693, August 2012.
829 6.2. Informative References
831 [George2014]
832 Xylomenos, G. Ververidis, C. N., Siris, V. A., Fotiou, N.,
833 Tsilopoulos, C., Vasilakos, X., Katsaros, K. V. Polyzos, G.
834 C., "A Survey of Information-Centric Networking Research",
835 IEEE Communications Surveys and Tutorials, Vol. 16, No. 2,
836 2014.
838 [Edo2014] Monticelli, E., Schubert, B. M., Arumaithurai, M., Fu, X.,
839 Ramakrishnan, K. K., "An Information Centric Approach for
840 Communications in Disaster Situations," Proceedings of
841 IEEE Local & Metropolitan Area Networks, USA, May 2014.
843 [Hass2006]
844 Hass, Z. J., Small, T., "A new networking model for
845 biological applications of ad hoc sensor networks",
846 IEEE/ACM Transactions on Networking, Vol. 14, No. 1, pp.
847 27-40, Feb.,2006.
849 Authors' Addresses
851 Yun Won Chung
852 Soongsil University
853 369, Sangdo-ro, Dongjak-gu,
854 Seoul, 06978, Korea
856 Email: ywchung@ssu.ac.kr
858 Min Wook Kang
859 Soongsil University
860 369, Sangdo-ro, Dongjak-gu,
861 Seoul, 06978, Korea
863 Email: goodlookmw@gmail.com
865 Younghan Kim
866 Soongsil University
867 369, Sangdo-ro, Dongjak-gu,
868 Seoul, 06978, Korea
870 Email: younghak@ssu.ac.kr