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