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