idnits 2.17.1 draft-ietf-udlr-lltunnel-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 77: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 78: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 116: '... communication interfaces. A feed MUST...' RFC 2119 keyword, line 333: '... feed MUST maintain a list of all ot...' RFC 2119 keyword, line 334: '... list MUST indicate which are send-o...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Duros 3 Internet-Draft W. Dabbous 4 April 2000 INRIA Sophia-Antipolis 5 H. Izumiyama 6 N. Fujii 7 WIDE 8 Y. Zhang 9 HRL 11 A Link Layer Tunneling Mechanism for Unidirectional Links 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 A version of this draft document is intended for submission to the 36 RFC editor as a Proposed Standard for the Internet Community. 38 Abstract 40 This document describes a mechanism to emulate bidirectional 41 connectivity between nodes that are directly connected by a 42 unidirectional link. The "receiver" uses a link layer tunneling 43 mechanism to forward datagrams to "feeds" over a separate 44 bidirectional IP network. As it is implemented at the link layer, 45 protocols in addition to IP may also be supported by this mechanism. 47 1. Introduction 49 Internet routing and upper layer protocols assume that links are 50 bidirectional, i.e., directly connected hosts can communicate with 51 each other over the same link. 53 This document describes a link layer tunneling mechanism that allows 54 nodes which are directly connected by a unidirectional link (feeds 55 and receivers, see Section 2 for terminology) to send datagrams as if 56 they were connected to a bidirectional link. We present a generic 57 topology with a tunneling mechanism that supports multiple feeds and 58 receivers. 60 The tunneling mechanism requires that all nodes have an additional 61 interface to an IP interconnected infrastructure. 63 The tunneling mechanism is implemented at the link layer of the 64 interface of every node connected to the unidirectional link. The aim 65 is to hide from higher layers, i.e. the network layer and above, the 66 unidirectional nature of the link. The tunneling mechanism also 67 includes an automatic tunnel configuration protocol that allows nodes 68 to come up/down at any time. 70 Generic Routing Encapsulation [rfc2784] is suggested as the tunneling 71 mechanism as it provides a means for carrying IP, ARP datagrams, and 72 any other layer-3 protocol between nodes. 74 The tunneling mechanism described in this document was discussed and 75 agreed upon by the UDLR working group. 77 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 78 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 79 document, are to be interpreted as described in [rfc2119]. 81 2. Terminology 83 Unidirectional link (UDL): A one way transmission link, e.g. a 84 broadcast satellite link. 86 Receiver: A router or a host that has receive-only connectivity to a 87 UDL. 89 Send-only feed: A router that has send-only connectivity to a UDL. 91 Receive capable feed: A router that has send-and-receive connectivity 92 to a UDL. 94 Feed: A send-only or a receive capable feed. 96 Node: A receiver or a feed. 98 3. Topology 100 Feeds and receivers are connected via a unidirectional link. Send- 101 only feeds can only send data over this unidirectional link, and 102 receivers can only receive data from it. Receive capable feeds have 103 both send and receive capabilities. 105 This mechanism has been designed to work with any topology with any 106 number of receivers and one or more feeds. However, it is expected 107 that the number of feeds will be small. In particular, the special 108 case of a single send-only feed and multiple receivers is among the 109 topologies supported. 111 A receiver has several interfaces, a receive-only interface and one 112 or more additional bidirectional communication interfaces. 114 A feed has several interfaces, a send-only or a send-and-receive 115 capable interface connected to the unidirectional link and one or 116 more additional bidirectional communication interfaces. A feed MUST 117 be a router. 119 Tunnels are constructed between the bidirectional interfaces of 120 nodes, so these interfaces must be interconnected by an IP 121 infrastructure. In this document we assume that that infrastructure 122 is the Internet. 124 Figure 1 depicts a generic topology with several feeds and several 125 receivers. 127 Unidirectional Link 129 ---->---------->------------------->------ 130 | | | | 131 |f1u |f2u |r2u |r1u 132 -------- -------- -------- -------- ---------- 133 |Feed 1| |Feed 2| |Recv 2| |Recv 1|---|subnet A| 134 -------- -------- -------- -------- ---------- 135 |f1b |f2b |r2b |r1b | 136 | | | | | 137 ---------------------------------------------------- 138 | Internet | 139 ---------------------------------------------------- 140 Figure 1: Generic topology 142 f1u (resp. f2u) is the IP address of the 'Feed 1' (resp. Feed 2) 143 send-only interface. 145 f1b (resp. f2b) is the IP address of the 'Feed 1' (resp. Feed 2) 146 bidirectional interface connected to the Internet. 148 r1u (resp. r2u) is the IP address of the 'Receiver 1' (resp. Receiver 149 2) receive-only interface. 151 r1b (resp. r2b) is the IP address of the 'Receiver 1' (resp. Receiver 152 2) bidirectional interface connected to the Internet. 154 Subnet A is a local area network connected to recv1. 156 Note that nodes have IP addresses on their unidirectional and their 157 bidirectional interfaces. The addresses on the unidirectional 158 interfaces (f1u, f2u, r1u, r2u) will be drawn from the same IP 159 network. In general the addresses on the bidirectional interfaces 160 (f1b, f2b, r1b, r2b) will be drawn from different IP networks, and 161 the Internet will route between them. 163 4. Problems related to unidirectional links 165 Receive-only interfaces are "dumb" and send-only interfaces are 166 "deaf". Thus a datagram passed to the link layer driver of a 167 receive-only interface is simply discarded. The link layer of a 168 send-only interface never receives anything. 170 The network layer has no knowledge of the underlying transmission 171 technology except that it considers its access as bidirectional. 172 Basically, for outgoing datagrams, the network layer selects the 173 correct first hop on the connected network according to a routing 174 table and passes the packet(s) to the appropriate link layer driver. 176 Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. 177 However, if Recv 1 initiates a 'ping f1u', it cannot get a response 178 from Feed 1. The network layer of Recv 1 delivers the packet to the 179 driver of the receive-only interface, which obviously cannot send it 180 to the feed. 182 Many protocols in the Internet assume that links are bidirectional. 183 In particular, routing protocols used by directly connected routers 184 no longer behave properly in the presence of a unidirectional link. 186 5. Emulating a broadcast bidirectional network 187 The simplest solution is to emulate a broadcast capable link layer 188 network. This will allow the immediate deployment of existing higher 189 level protocols without change. Though other network structures, such 190 as NBMA, could also be emulated, a broadcast network is more 191 generally useful. Though a layer 3 network could be emulated, a link 192 layer network allows the immediate use of any other network layer 193 protocols, and most particularly allows the immediate use of ARP. 195 A link layer (LL) tunneling mechanism which emulates bidirectional 196 connectivity in the presence of a unidirectional link will be 197 described in the next Section. We first consider the various 198 communication scenarios which characterize a broadcast network in 199 order to define what functionalities the link layer tunneling 200 mechanism has to perform in order to emulate a bidirectional 201 broadcast link. 203 Here we enumerate the scenarios which would be feasible on a 204 broadcast network, i.e. if feeds and receivers were connected by a 205 bidirectional broadcast link: 207 Scenario 1: A receiver can send a packet to a feed (point-to-point 208 communication between a receiver and a feed). 210 Scenario 2: A receiver can send a broadcast/multicast packet on the 211 link to all nodes (point-to-multipoint). 213 Scenario 3: A receiver can send a packet to another receiver (point- 214 to-point communication between two receivers). 216 Scenario 4: A feed can send a packet to a send-only feed (point-to- 217 point communication between two feeds). 219 Scenario 5: A feed can send a broadcast/multicast packet on the link 220 to all nodes (point-to-multipoint). 222 Scenario 6: A feed can send a packet to a receiver or a receive 223 capable feed. 225 These scenarios are possible on a broadcast network. Scenario 6 is 226 already feasible on the unidirectional link. The link layer tunneling 227 mechanism should therefore provide the functionality to support 228 scenarios 1 to 5. 230 Note that regular IP forwarding over such an emulated network (i.e. 231 using the emulated network as a transit network) works correctly; the 232 next hop address at the receiver will be the unidirectional link 233 address of another router (a feed or a receiver) which will then 234 relay the packet. 236 6. Link layer tunneling mechanism 238 This link layer tunneling mechanism operates underneath the network 239 layer. Its aim is to emulate bidirectional link layer connectivity. 240 This is transparent to the network layer: the link appears and 241 behaves to the network layer as if it was bidirectional. 243 Figure 2 depicts a layered representation of the link layer tunneling 244 mechanism in the case of Scenario 1. 246 Send-only Feed Receiver 248 decapsulation encapsulation 249 /-----***************----\ /-->---***************--\ 250 | | | | 251 | | | | 252 --|---------------------- | | ---------------------|--- 253 | | f1b | f1u | | | | x r1u | r1b | | 254 | | | ^ | | IP | | | | v | 255 | ^ | | | v | | | | | | 256 | | | | | | | | v | | | 257 |-|---------|-------|---| | | |----|------|--------|--| 258 | | | | | | ^ | | | | | 259 | | | | | | LL | | | | | | 260 | | | | | | | | | | | | 261 | | | O------/ \<------O | | | 262 |-|---------|-----------| |-----------|--------|--| 263 | | | | | | | | 264 | | | | PHY | | | | 265 | | | | | | v | 266 | | | | | | | | | | 267 --|-----------|---------- ----------|----------|--- 268 | Bidir | Send-Only Recv-Only | Bidir | 269 ^ Interf | Interf UDL Interf | Interf | 270 | \------------>------->------------/ | 271 \----------------------<------------------------<--------/ 272 Bidirectional network 274 x : IP layer at the receiver generates a datagram to be forwarded 275 on the receive-only interface. 276 O : Entry point where the link layer tunneling mechanism is 277 triggered. 279 Figure 2: Scenario 1 using the LL Tunneling Mechanism 281 6.1. Tunneling mechanism on the receiver 282 On the receiver, a datagram is delivered to the link layer of the 283 unidirectional interface for transmission (see Figure 2). It is then 284 encapsulated behind a MAC header corresponding to the unidirectional 285 link. This packet cannot be sent directly over the link, so it is 286 then processed by the tunneling mechanism. 288 The packet is encapsulated behind an IP header whose destination is 289 the IP address of a feed bidirectional interface (f1b or f2b). This 290 destination address is also called the tunnel end-point. The 291 mechanism for a receiver to learn these addresses and to choose the 292 feed is explained in Section 7. The type of encapsulation is 293 described in Section 8. 295 In all cases the packet is encapsulated, but the tunnel end-point (an 296 IP address) depends on the encapsulated packet's destination MAC 297 address. If the destination MAC address is: 299 1) the MAC address of a feed interface connected to the 300 unidirectional link (Scenario 1). The datagram is encapsulated, 301 the destination address of the encapsulating datagram is the 302 feed tunnel end-point (f1b referring to Figure 2). 304 2) a MAC broadcast/multicast address (Scenario 2). The datagram is 305 encapsulated, the destination address of the encapsulating 306 datagram is the default feed tunnel end-point. See Section 7.4 307 for further details on the default feed. 309 3) a MAC address that belongs to the unidirectional network but is 310 not a feed address (Scenario 3). The datagram is encapsulated, 311 the destination address of the encapsulating datagram is the 312 default feed tunnel end-point. 314 The encapsulated datagram is passed to the network layer which 315 forwards it according to its destination address. The destination 316 address is a feed bidirectional interface which is reachable via the 317 Internet. In this case, the encapsulated datagram is forwarded via 318 the receiver bidirectional interface (r1b). 320 6.2. Tunneling mechanism on the feed 322 A feed processes unidirectional link related packets in two different 323 ways: 324 - packets generated by a local application or packets routed as 325 usual by the IP layer may have to be forwarded over the 326 unidirectional link (Section 6.2.1) 327 - encapsulated packets received from another receiver or feed need 328 tunnel processing (Section 6.2.2). 330 A feed cannot directly send a packet to a send-only feed over the 331 unidirectional link (Scenario 4). In order to emulate this type of 332 communication, feeds have to tunnel packets to send-only feeds. A 333 feed MUST maintain a list of all other feed tunnel end-points. This 334 list MUST indicate which are send-only feed tunnel end-points. This 335 is configured manually at the feed by the local administrator, as 336 described in Section 7. 338 6.2.1. Forwarding packets over the unidirectional link 340 When a datagram is delivered to the link layer of the unidirectional 341 interface of a feed for transmission, its treatment depends on the 342 packet's destination MAC address. If the destination MAC address is: 344 1) the MAC address of a receiver or a receive capable feed 345 (Scenario 6). The packet is sent over the unidirectional link. 346 This is classical "forwarding". 348 2) the MAC address of a send-only feed (Scenario 4). The packet is 349 encapsulated and sent to the send-only feed tunnel end-point. 350 The type of encapsulation is described in Section 8. 352 3) a broadcast/multicast destination (Scenario 5). The packet is 353 sent over the unidirectional link. Concurrently, a copy of this 354 packet is encapsulated and sent to every feed of the list of 355 send-only feed tunnel end-points. Thus the broadcast/multicast 356 will reach all receivers and all send-only feeds. 358 6.2.2. Receiving encapsulated packets 360 Feeds listen for incoming encapsulated datagrams on their tunnel end- 361 points. Encapsulated packets will have been received on a 362 bidirectional interface, and traversed their way up the IP stack. 363 They will then enter a decapsulation process (See Figure 2). 365 Decapsulation reveals the original link layer packet. Note that this 366 has not been modified in any way by intermediate routers; in 367 particular, the original MAC header will be intact. 369 Further actions depend on the destination MAC address of the link 370 layer packet, which can be: 372 1) the MAC address of the feed interface connected to the 373 unidirectional link, i.e. own MAC address (Scenarios 1 and 4). 374 The packet is passed to the link layer of the interface 375 connected to the unidirectional link which can then deliver it 376 up to higher layers. As a result, the datagram is processed as 377 if it was coming from the unidirectional link, and being 378 delivered locally. Scenarios 1 and 4 are now feasible, a 379 receiver or a feed can send a packet to a feed. 381 2) a receiver address (Scenario 3). The packet is passed to the 382 link layer of the interface connected to the unidirectional 383 link. It is directly sent over the unidirectional link, to the 384 indicated receiver. Note, the packet must not be delivered 385 locally. Scenario 3 is now feasible, a receiver can send a 386 packet to another receiver. 388 3) a broadcast/multicast address, this corresponds to Scenarios 2 389 and 5. We have to distinguish two cases, either (i) the 390 encapsulated packet was sent from a receiver or (ii) from a feed 391 (encapsulated broadcast/multicast packet sent to a send-only 392 feed). These cases are distinguished by examining the source 393 address of the encapsulating packet and comparing it with the 394 configured list of feed IP addresses. The action then taken is: 396 i) the feed was designated as a default feed by a receiver to 397 forward the broadcast/multicast packet. The feed is then in 398 charge of sending the multicast packet to all nodes. Delivery 399 to all nodes is accomplished by executing all 3 of the 400 following actions: 401 - The packet is encapsulated and sent to the list of send- 402 only feed tunnel end-points. 403 - Also, the packet is passed to the link layer of the 404 interface which forwards it directly over the 405 unidirectional link (all receivers and receive capable 406 feeds receive it). 407 - Also, the link layer delivers it locally to higher layers. 408 Caution: a receiver which sends an encapsulated 409 broadcast/multicast packet to a default feed will receive 410 its own packet via the unidirectional link. Correct 411 filtering as described in [rfc1112] must be applied. 413 ii) the feed receives the packet and keeps it for local 414 delivery. The packet is passed to the link layer of the 415 interface connected to the unidirectional link which delivers 416 it to higher layers. 418 Scenario 2 is now feasible, a receiver can send a 419 broadcast/multicast packet over the unidirectional link and it 420 will be heard by all nodes. 422 7. Dynamic Tunnel Configuration Protocol (DTCP) 424 Receivers and feeds have to know the feed tunnel end-points in order 425 to forward encapsulated datagrams (e.g. Scenarios 1 and 4). 427 The number of feeds is expected to be relatively small (Section 3), 428 so at every feed the list of all feeds is configured manually. This 429 list should note which are send-only feeds, and which are receive 430 capable feeds. The administrator sets up tunnels to all send-only 431 feeds. A tunnel end-point is an IP address of a bidirectional link on 432 a send-only feed. 434 For scalability reasons, manual configuration cannot be done at the 435 receivers. Tunnels must be configured and maintained dynamically by 436 receivers, both for scalability, and in order to cope with the 437 following events: 439 1) New feed detection. 440 When a new feed comes up, every receiver must create a tunnel to 441 enable bidirectional communication with it. 443 2) Loss of unidirectional link detection. 444 When the unidirectional link is down, receivers must disable 445 their tunnels. The tunneling mechanism emulates bidirectional 446 connectivity between nodes. Therefore, if the unidirectional 447 link is down, a feed should not receive datagrams from the 448 receivers. Protocols that consider a link as operational if they 449 receive datagrams from it (e.g. the RIP protocol [rfc2453]) 450 require this behavior for correct operation. 452 3) Loss of feed detection. 453 When a feed is down, receivers must disable their corresponding 454 tunnel. This prevents unnecessary datagrams from being tunneled 455 which might overload the Internet. For instance, there is no 456 need for receivers to forward a broadcast message through a 457 tunnel whose end-point is down. 459 The DTCP protocol provides a means for receivers to dynamically 460 discover the presence of feeds and to maintain a list of operational 461 tunnel end-points. Feeds periodically announce their tunnel end-point 462 addresses over the unidirectional link. Receivers listen to these 463 announcements and maintain a list of tunnel end-points. 465 7.1. The HELLO message 467 The DTCP protocol is a 'unidirectional protocol', messages are only 468 sent from feeds to receivers. 470 The packet format is shown in Figure 3. Fields contain binary 471 integers, in normal Internet order with the most significant bit 472 first. Each tick mark represents one bit. 474 0 1 2 3 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Vers | Com | Interval | Sequence | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | res |F|IP Vers| Tunnel Type | Nb of FBIP | reserved | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Feed BDL IP addr (FBIP1) (32/128 bits) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | ..... | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Feed BDL IP addr (FBIPn) (32/128 bits) | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 3: Packet Format 490 Every datagram contains the following fields, note that constants are 491 written in uppercase and are defined in Section 7.5: 493 Vers (4 bit unsigned integer): DTCP version number. MUST be 494 DTCP_VERSION. 496 Com (4 bit unsigned integer): Command field, possible values are 497 1 - JOIN A message announcing that the feed sending this message 498 is up and running. 499 2 - LEAVE A message announcing that the feed sending this message 500 is being shut down. 502 Interval (8 bit unsigned integer): Interval in seconds between HELLO 503 messages for the IP protocol in "IP Vers". Must be > 0. The 504 recommended value is HELLO_INTERVAL. If this value is increased, 505 the feed MUST continue to send HELLO messages at the old rate for 506 at least the old HELLO_LEAVE period. 508 Sequence (16 bit unsigned integer): Random value initialized at boot 509 time and incremented by 1 every time a value of the HELLO message 510 is modified. 512 res (3 bits): Reserved/unused field, MUST be zero. 514 F (1 bit): bit indicating the type of feed: 515 0 = Send-only feed 516 1 = Receive-capable feed 518 IP Vers (4 bit unsigned integer): IP protocol version of the feed 519 bidirectional IP addresses (FBIP): 520 4 = IP version 4 521 6 = IP version 6 523 Tunnel Type (8 bit unsigned integer): tunneling protocol supported by 524 the feed; receivers MUST use this form of tunnel encapsulation when 525 tunneling to the feed. 526 47 = GRE [rfc2784] (recommended) 527 Other values may be used, but their interpretation is not specified 528 here. 530 Nb of FBIP (8 bit unsigned integer): Number of bidirectional IP feed 531 addresses which are enumerated in the HELLO message 533 reserved (8 bits): Reserved/unused field, MUST be zero. 535 Feed BDL IP addr (32 or 128 bits). The bidirectional IP address feed 536 is the IP address of a feed bidirectional interface (tunnel end- 537 point) reachable via the Internet. A feed has 'Nb of FBIP' IP 538 addresses which are operational tunnel end-points. They are 539 enumerated in preferred order. FBIP1 being the most suitable tunnel 540 end-point. 542 7.2. DTCP on the feed: sending HELLO packets 544 The DTCP protocol runs on top of UDP. Packets are sent to the "DTCP 545 announcement" multicast address over the unidirectional link on port 546 HELLO_PORT with a TTL of 1. 548 The source address of the HELLO packet is set to the IP address of 549 the feed interface connected to the unidirectional link. In the rest 550 of the document, this value is called FUIP (Feed Unidirectional IP 551 address). 553 The process in charge of sending HELLO packets fills every field of 554 the datagram according to the description given in Section 7.1. 556 As long as a feed is up and running, it periodically announces its 557 presence to receivers. It MUST send HELLO packets containing a JOIN 558 command every HELLO_INTERVAL over the unidirectional link. 560 Referring to Figure 1 in Section 3, Feed 1 (resp. Feed 2) sends HELLO 561 messages with the FBIP1 field set to f1b (resp. f2b). 563 When a feed is about to be shut down, or when routing over the 564 unidirectional link is about to be intentionally interrupted, it is 565 recommended that feeds: 567 1) stop sending HELLO messages containing a JOIN command. 569 2) send a HELLO message containing a LEAVE command to inform 570 receivers that the feed is no longer performing routing over the 571 unidirectional link. 573 7.3. DTCP on the receiver: receiving HELLO packets 575 Based on the reception of HELLO messages, receivers discover the 576 presence of feeds, maintain a list of active feeds, and keep track of 577 the tunnel end-points for those feeds. 579 For each active feed, and each IP protocol supported, at least the 580 following information will be kept: 581 FUIP - feed unidirectional link IP address 582 FUMAC - MAC address corresponding to the above IP 583 address 584 (FBIP1,...,FBIPn) - list of tunnel end-points 585 tunnel type - tunnel type supported by this feed 586 Sequence - "Sequence" value from the last HELLO received 587 from this feed 588 timer - used to timeout this entry 590 The FUMAC value for an active feed is needed for the operation of 591 this protocol. However, the method of discovery of this value is not 592 specified here. 594 Initially, the list of active feeds is empty. 596 When a receiver is started, it MUST run a process which joins the 597 "DTCP announcement" multicast group and listens to incoming packets 598 on the HELLO_PORT port from the unidirectional link. 600 Upon the reception of a HELLO message, the process checks the version 601 number of the protocol. If it is different from HELLO_VERSION, the 602 packet is discarded and the process waits for the next incoming 603 packet. 605 After successfully checking the version number further action depends 606 on the type of command: 608 - JOIN: 610 The process verifies if the address FUIP already belongs to the 611 list of active feeds. 613 If it does not, a new entry, for feed FUIP, is created and added 614 to the list of active feeds. The number of feed bidirectional IP 615 addresses to read is deduced from the 'Nb of FBID' field. These 616 tunnel end-points (FBIP1,...,FBIPn) can then be added to the new 617 entry. The tunnel Type and Sequence values are also taken from the 618 HELLO packet and recorded in the new entry. A timer set to 619 HELLO_LEAVE is associated with this entry. 621 If it does, the sequence number is compared to the sequence number 622 contained in the previous HELLO packet sent by this feed. If they 623 are equal, the timer associated with this entry is reset to 624 HELLO_LEAVE. Otherwise all the information corresponding to FUIP 625 is set to the values from the HELLO packet. 627 Referring to Figure 1 in Section 3, both receivers (recv 1 and 628 recv 2) have a list of active feeds containing two entries: Feed 1 629 with a FUIP of f1u and a list of tunnel end-points (f1b); and Feed 630 2 with a FUIP of f2u and a list of tunnel end-points (f2b). 632 - LEAVE: 634 The process checks if there is an entry for FUIP in the list of 635 active feeds. If there is, the timer is disabled and the entry is 636 deleted from the list. The LEAVE message provides a means of 637 quickly updating the list of active feeds. 639 A timeout occurs for either of two reasons: 641 1) a feed went down without sending a LEAVE message. As JOIN 642 messages are no longer sent from this feed, a timeout occurs at 643 HELLO_LEAVE after the last JOIN message. 645 2) the unidirectional link is down. Thus no more JOIN messages are 646 received from any of the feeds, and they will each timeout 647 independently. The timeout of each entry depends on its 648 individual HELLO_LEAVE value, and when the last JOIN message was 649 sent by that feed, before the unidirectional link went down. 651 In either case, bidirectional connectivity can no longer be ensured 652 between the receiver and the feed (FUIP): either the feed is no 653 longer routing datagrams over the unidirectional link, or the link is 654 down. Thus the associated entry is removed from the list of active 655 feeds, whatever the cause. As a result, the list only contains 656 operational tunnel end-points. 658 The HELLO protocol provides receivers with a list of feeds, and a 659 list of usable tunnel end-points (FBIP1,..., FBIPn) for each feed. In 660 the following Section, we describe how to integrate the HELLO 661 protocol into the tunneling mechanism described in Sections 6.1 and 662 6.2. 664 7.4. Tunneling mechanism using the list of active feeds 666 This Section explains how the tunneling mechanism uses the list of 667 active feeds to handle datagrams which are to be tunneled. Referring 668 to Section 6.1, it shows how feed tunnel end-points are selected. 670 The choice of the default feed is made independently at each 671 receiver. The choice is a matter of local policy, and this policy is 672 out of scope for this document. However, as an example, the default 673 feed may be the feed that has the lowest round trip time to the 674 receiver. 676 When a receiver sends a packet to a feed, it must choose a tunnel 677 end-point from within the FBIP list. The 'preferred FBIP' is 678 generally FBIP1 (Section 7.1). For various reasons, a receiver may 679 decide to use a different FBIP, say FBIPi instead of FBIP1, as the 680 tunnel end-point. For example, the receiver may have better 681 connectivity to FBIPi. This decision is taken by the receiver 682 administrator. 684 Here we show how the list of active feeds is involved when a receiver 685 tunnels a link layer packet. Section 6.1 listed the following cases, 686 depending on whether the MAC destination address of the packet is: 688 1) the MAC address of a feed interface connected to the 689 unidirectional link: This is TRUE if the address matches a FUMAC 690 address in the list of active feeds. The packet is tunneled to 691 the preferred FBIP of the matching feed. 693 2) the broadcast address of the unidirectional link or a multicast 694 address: 695 This is determined by the MAC address format rules, and the list 696 of active feeds is not involved. The packet is tunneled to the 697 preferred FBIP of the default feed. 699 3) an address that belongs to the unidirectional network but is not 700 a feed address: 701 This is TRUE if the address is neither broadcast nor multicast, 702 nor found in the list of active feeds. The packet is tunneled to 703 the preferred FBIP of the default feed. 705 In all cases, the encapsulation type depends on the tunnel type 706 required by the feed which is selected. 708 7.5. Constant definitions 710 DTCP_VERSION is 1. 712 HELLO_INTERVAL is 5 seconds. 714 "DTCP announcement" multicast group is 224.0.1.124. 716 HELLO_PORT is 652. It is a reserved system port, no other traffic 717 must be allowed. 719 HELLO_LEAVE is 3*Interval, as advertised in a HELLO packet, i.e. 15 720 seconds if the default HELLO_INTERVAL was advertised. 722 8. Tunnel encapsulation format 724 The tunneling mechanism operates at the link layer and emulates 725 bidirectional connectivity amongst receivers and feeds. We assume 726 that hardware connected to the unidirectional link supports broadcast 727 and unicast MAC addressing. That is, a feed can send a packet to a 728 particular receiver using a unicast MAC destination address or to a 729 set of receivers using a broadcast/multicast destination address. The 730 hardware (or the driver) of the receiver can then filter the incoming 731 packets sent over the unidirectional links without any assumption 732 about the encapsulated data type. 734 In a similar way, a receiver should be capable of sending unicast and 735 broadcast MAC packets via its tunnels. Link layer packets are 736 encapsulated. As a result, after decapsulating an incoming packet, 737 the feed can perform link layer filtering as if the data came 738 directly from the unidirectional link (See Figure 2). 740 Generic Routing Encapsulation (GRE) [rfc2784] suits our requirements 741 because it specifies a protocol for encapsulating arbitrary packets, 742 and allows use of IP as the delivery protocol. 744 Other encapsulations are possible, such as directly encapsulating a 745 MAC level packet within an IP datagram. 747 The feed's local administrator decides what encapsulation it will 748 demand that receivers use, and sets the tunnel type field in the 749 HELLO message appropriately. The value 47 (decimal) indicates GRE. 750 Other values can be used, but their interpretation must be agreed 751 upon between feeds and receivers. Such usage is not defined here. 753 8.1. Generic Routing Encapsulation on the receiver 755 A GRE packet is composed of a header in which a type field specifies 756 the encapsulated protocol (ARP, IP, IPX, etc.). See [rfc2784] for 757 details about the encapsulation. In our case, only support for the 758 MAC addressing scheme of the unidirectional link MUST be implemented. 760 A packet tunneled with a GRE encapsulation has the following format: 761 the delivery header is an IP header whose destination is the tunnel 762 end-point (FBIP), followed by a GRE header specifying the link layer 763 type of the unidirectional link. Figure 4 presents the entire 764 encapsulated packet. 766 ---------------------------------------- 767 | IP delivery header | 768 | destination addr = FBIP | 769 | IP proto = GRE (47) | 770 ---------------------------------------- 771 | GRE Header | 772 | type = MAC type of the UDL | 773 ---------------------------------------- 774 | Payload packet | 775 | MAC packet | 776 ---------------------------------------- 778 Figure 4: Encapsulated packet 780 8.2. Encapsulation of UDL MAC level packets 782 An alternative is to encapsulate the MAC level packet within IP. The 783 protocol field in the IP datagram is then set to the MAC type of the 784 unidirectional link. Figure 5 presents the entire encapsulated 785 packet. 787 ---------------------------------------- 788 | IP delivery header | 789 | destination addr = FBIP | 790 | IP proto = MAC type of the UDL | 791 ---------------------------------------- 792 | Payload packet | 793 | MAC packet | 794 ---------------------------------------- 796 Figure 5: Encapsulated packet 798 9. Issues 800 9.1. Hardware address resolution 802 Regardless of whether the link is unidirectional or bidirectional, if 803 a feed sends a packet over a non-point-to-point type network, it 804 requires the data link address of the destination. ARP [rfc826] is 805 used on Ethernet networks for this purpose. 807 The link layer mechanism emulates a bidirectional network in the 808 presence of an unidirectional link. However, there are asymmetric 809 delays between every (feed, receiver) pair. The backchannel between a 810 receiver and a feed has varying delays because packets go through the 811 Internet. Furthermore, a typical example of a unidirectional link is 812 a GEO satellite link whose delay is about 250 milliseconds. 814 Because of long round trip delays, reactive address resolution 815 methods such as ARP [rfc826] may not work well. For example, a feed 816 may have to forward packets at high data rates to a receiver whose 817 hardware address is unknown. The stream of packets is passed to the 818 link layer driver of the feed send-only interface. When the first 819 packet arrives, the link layer realizes it does not have the 820 corresponding hardware address of the next hop, and sends an ARP 821 request. While the link layer is waiting for the response (at least 822 250 ms for the GEO satellite case), IP packets are buffered by the 823 feed. If it runs out of space before the ARP response arrives, IP 824 packets will be dropped. 826 This problem of address resolution protocols is not addressed in this 827 document. An ad-hoc solution is possible when the MAC address is 828 configurable, which is possible in some satellite receiver cards. A 829 simple transformation (maybe null) of the IP address can then be used 830 as the MAC address. In this case, senders do not need to "resolve" an 831 IP address to a MAC address, they just need to perform the simple 832 transformation. 834 9.2. Routing protocols 836 The link layer tunneling mechanism hides from the network and higher 837 layers the fact that feeds and receivers are connected by a 838 unidirectional link. Communication is bidirectional, but asymmetric 839 in bandwidths and delays. 841 In order to incorporate unidirectional links in the Internet, feeds 842 and receivers might have to run routing protocols in some topologies. 843 These protocols will work fine because the tunneling mechanism 844 results in bidirectional connectivity between all feeds and 845 receivers. Thus routing messages can be exchanged as on any 846 bidirectional network. 848 The tunneling mechanism allows any IP traffic, not just routing 849 protocol messages, to be forwarded between receivers and feeds. 850 Receivers can route datagrams on the Internet using the most suitable 851 feed or receiver as a next hop. Administrators may want to set the 852 metrics used by their routing protocols in order to reflect in 853 routing tables the asymmetric characteristics of the link, and thus 854 direct traffic over appropriate paths. 856 Feeds and receivers may implement multicast routing and therefore 857 dynamic multicast routing can be performed over the unidirectional 858 link. However issues related to multicast routing (e.g. protocol 859 configuration) are not addressed in this document. 861 9.3. Scalability 863 The DTCP protocol does not generate a lot of traffic whatever the 864 number of nodes. The problem with a large number of nodes is not 865 related to this protocol but to more general issues such as the 866 maximum number of nodes which can be connected to any link. This is 867 out of scope of this document. 869 10. Security Considerations 871 Security in a network using the link layer tunneling mechanism should 872 be relatively similar to security in a normal IPv4 network. However, 873 as the link layer tunneling mechanism uses GRE[rfc2784], it is 874 expected that GRE authentication mechanism combined with a specific 875 link layer security mechanism on the back-channel will help to 876 enhance security in a unidirectional link environment. 878 In order to prevent unauthorised users from providing fake routing 879 information, routing protocols running on top of the link layer 880 tunneling mechanism MUST use authentication mechanisms when 881 available. 883 11. Acknowledgments 885 We would like to thank Tim Gleeson (Cisco Japan) for his valuable 886 editing and technical input during the finalization phase of the 887 document. 889 We would like to thank Patrick Cipiere (INRIA) for his valuable input 890 concerning the design of the encapsulation mechanism. 892 We would like also to thank for their participation: Akihiro Tosaka 893 (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi 894 Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), 895 Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu 896 (Sony CSL), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri 897 Hakulinen (Nokia). 899 A. Conformance and interoperability 901 This document describes a mechanism to emulate bidirectional 902 connectivity between nodes that are directly connected by a 903 unidirectional link. Applicability over a variety of equipment and 904 environments is ensured by allowing a choice of several key system 905 parameters. 907 Thus in order to ensure interoperability of equipment it is not 908 enough to simply claim conformance with the mechanism defined here. A 909 usage profile for a particular environment will require the 910 definition of several parameters: 911 - the MAC format used 912 - the tunneling mechanism to be used (GRE is recommended) 913 - the "tunnel type" indication if GRE is not used 915 For example, a system might claim to implement "the link layer 916 tunneling mechanism for unidirectional links, using IEEE 802 LLC, and 917 GRE encapsulation for the tunnels." 919 References 921 [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, 922 November 1982. 924 [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford 925 University, August 1989 927 [rfc2119] 'Key words for use in RFCs to Indicate Requirement Levels', 928 S. Bradner, Harvard University, March 1997 930 [rfc2401] 'Security Architecture for the Internet Protocol', S. Kent, 931 BBN Corp, R. Atkinson, @Home Network 933 [rfc2402] 'IP Authentication Header', S. Kent, BBN Corp, R. Atkinson, 934 @Home Network 936 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 938 [rfc2784] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li, 939 Procket Networks, S. Hanks, Enron Communications, D. Meyer, 940 Cisco Systems, P. Traina, Juniper Networks, March 2000 942 Author's address 944 Emmanuel Duros 945 INRIA Sophia Antipolis 946 2004, Route des Lucioles BP 93 947 06902 Sophia Antipolis 948 France 949 Phone : +33 4 92 38 79 42 950 Fax : +33 4 92 38 79 78 951 Email : Emmanuel.Duros@inria.fr 953 Walid Dabbous 954 INRIA Sophia Antipolis 955 2004, Route des Lucioles BP 93 956 06902 Sophia Antipolis 957 France 958 Phone : +33 4 92 38 77 18 959 Fax : +33 4 92 38 79 78 960 Email : Walid.Dabbous@inria.fr 962 Hidetaka Izumiyama 963 JSAT Corporation 964 Toranomon 17 Mori Bldg.5F 965 1-26-5 Toranomon, Minato-ku 966 Tokyo 105 967 Japan 968 Voice : +81-3-5511-7568 969 Fax : +81-3-5512-7181 970 Email : izu@jsat.net 972 Noboru Fujii 973 Sony Corporation 974 2-10-14 Osaki, Shinagawa-ku 975 Tokyo 141 976 Japan 977 Voice : +81-3-3495-3092 978 Fax : +81-3-3495-3527 979 Email : fujii@dct.sony.co.jp 981 Yongguang Zhang 982 HRL 983 RL-96, 3011 Malibu Canyon Road 984 Malibu, CA 90265, 985 USA 986 Phone : 310-317-5147 987 Fax : 310-317-5695 988 Email : ygz@hrl.com