idnits 2.17.1 draft-demizu-udlr-dtcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 108: '... time, each node SHOULD obey the follo...' RFC 2119 keyword, line 112: '... - A Feeder SHOULD send DTCP Anno...' RFC 2119 keyword, line 115: '... SHOULD be fixed during the F...' RFC 2119 keyword, line 119: '... - A Receiver MUST wait for random ...' RFC 2119 keyword, line 124: '... Other Recievers SHOULD NOT respond to...' (37 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Op: 0 = DTCP Announcement message Code: 0 = DTCP_CODE_OK This Feeder is active and new tunnels can be set up with this Feeder. 1 = DTCP_CODE_FULL This Feeder is active but new tunnels cannot be set up with this Feeder. e.g. address pool is empty, or a tunnel table is full. 2 = DTCP_CODE_GOINGDOWN This Feeder will be down soon. Interval: - Interval time in second to send a DTCP Announcement message. The recommended interval is DTCP_ANN_INTERVAL. This field SHOULD not be changed during the Feeder keeps sending DTCP Announcement messages. Sequence: - Sequence number of DTCP Announcemenet messages. A Feeder SHOULD assign an initial random number when it boots so that Receivers can recognize this Feeder' rebooting from the big change of this field. The next sequence number of 2^16-1 is 0. Pattern: - This field is to limit the number of Receivers that can respond to a DTCP Announcemnet message to avoid a flood of DTCP messages. Only Receivers who satisfies following expression are allowed to respond. (Reciever_ID) & MASK == pattern & MASK, where MASK = (1 << Pattern_Length) - 1 - Unused pattern bits SHOULD be zero. Pattern Length: - See the explanation for pattern field. RecvID type: (Receiver-ID type) - See the explanation for pattern field. 0 = Receiver BDL IP address 1 = Receiver MAC address Feeder ID: - Identity information of the Feeder. This field will be used to select a Feeder by Receivers. --(TBD)--UDL Netmask: - the netmask of the UDL Feeder BDL IP addr: - Feeder BDL IP address -- 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.) -- The document date (November 1997) is 9631 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'T' on line 647 -- Looks like a reference, but probably isn't: 'C' on line 649 == Unused Reference: '2' is defined on line 688, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Noritoshi Demizu 3 Internet Draft SonyCSL, Inc. 4 Expiration Date: May 1998 5 Hidetaka Izumiyama 6 Japan Satellite Systems, Inc. 8 November 1997 10 Dynamic Tunnel Configuration Protocol 11 13 Status of this memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet- 28 Drafts Shadow Directories on ftp.is.co.za (Africa), 29 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 30 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 As the Internet grows, the importance of Uni-Directional Links such 35 as satellite links has been increasing. However, most of existing 36 routing protocols assume that datalinks are bi-directional. To 37 incorporate UDLs into the Internet, an IP tunneling approach has been 38 proposed, where tunnels are set up as a virtual back-channel of a UDL 39 to carry routing information between Feeders and Receivers. 41 Dynamic Tunnel Configuration Protocol (DTCP) supports to setup 42 tunnels dynamically between Feeders and Receivers in such 43 environments. 45 1. Introduction 47 To use Uni-Directional Link (UDL) such as satellite links as an IP 48 route, an IP tunneling approach[1] has been prpoposed. In this 49 approach, tunnels are set up as a virtual back-channel of a UDL to 50 carry routing information between Feeders and Receivers. Some of 51 such UDLs might have only one Feeder, others might have more than 52 one. 54 Dynamic Tunnel Configuration Protocol (DTCP) supports to setup 55 tunnels dynamically between Feeders and Receivers in that 56 environments. The main roles of DTCP are: 57 - to notify the availability of the Feeder to Receivers. 58 - to exchange node information that is necessary to transfer packets 59 through a UDL (e.g. MAC addresses of Receivers to forward unicast 60 packets) 61 - to establish and to release tunnels dynamically, including dynamic 62 IP address allocation for Receivers if necessary. 64 Here is the outline of the procedure to start using a UDL as an IP 65 route with DTCP: 66 1. Feeders send a "DTCP Announcement" message to a UDL periodically. 67 2. When a Receiver hears this message and it wants to use the UDL, 68 it sends a "DTCP Request" message to a Feeder to establish a 69 tunnel between the Feeder and the Receiver. Receiver MAC 70 address is included in this message. 71 3. The Feeder sends back a "DTCP Reply" message to the Receiver to 72 notify of acceptance or rejection. If the Feeder accepts the 73 request, a tunnel is established between the Feeder and the 74 Receiver. A UDL IP address is dynamically allocated to the 75 Receiver, if it does not have a statically allocated UDL IP 76 address. 77 4. The Feeder and the Receiver exchange routing information over 78 the tunnel and the UDL to use the UDL as an IP route. 79 5. Packets start to go through the UDL. 81 As figured above, DTCP helps the procedure 1. through 3. The 82 procedure 4. and 5. are out of the scope of this document. Feeder 83 selection algorithm by Receivers for the case where multiple Feeders 84 exist on a UDL is also out of the scope of this document. 86 This document specifies the format and semantics of DTCP. Section 2 87 outlines how DTCP works in the environment of [1]. Section 3 88 specifies the DTCP format and the meanings of each field. Section 4 89 depicts DTCP state transition diagram. Section 5 recommends default 90 values of constants used in this document. 92 2. The outline of DTCP 94 DTCP has four types of messages. These messages can be categorized 95 into following two: 97 1. DTCP Announcement message: "Announcement" 98 - This message is periodically sent from each Feeder to 99 Receivers to notify the avalability of the Feeder. 101 2. DTCP Tunnel Setup messages: "Request", "Reply", "Release" 102 - These messages are triggered by a DTCP Announcement message. 103 The aims of these messages are to establish and to release 104 tunnels dynamically. 106 In the environment of [1], there can be many Receivers per one 107 Feeder. To avoid that a flood of messages comes to a Feeder from 108 many Receivers at the same time, each node SHOULD obey the following 109 rules when sending messages: 111 1. DTCP Announcement message: 112 - A Feeder SHOULD send DTCP Announcement messages at the 113 interval rate as the Feeder specifies in the "interval" 114 field of DTCP Announcement messages. The interval rate 115 SHOULD be fixed during the Feeder keeps sending the 116 messages. 118 2. DTCP Tunnel Setup messages: 119 - A Receiver MUST wait for random seconds between 0 to 120 DTCP_ANN_WAIT before sending a message triggered by a DTCP 121 Announcement message. 122 - Only Receivers that are specified by the pattern field of a 123 trigger DTCP Announcement message can send a response 124 message. Other Recievers SHOULD NOT respond to the DTCP 125 Announcement message. 126 - When a Feeder is willing to send messages to all Receivers 127 that has a tunnel with the Feeder, the Feeder SHOULD wait 128 for random seconds between 0 to DTCP_ANN_WAIT before sending 129 a message to each Receiver. 130 - In other cases, any messages can be sent any time. 132 If a Receiver has not heard any DTCP Announcement message after its 133 boot, or if a Receiver does not hear DTCP Announcement messages for 134 more than DTCP_ANN_TIMEOUT from a Feeder, or when a Feeder does not 135 send a DTCP Announcement message periodically, a Receiver and a 136 Feeder SHOULD assume DTCP_ANN_INTERVAL as the announced interval 137 rate. 139 Since Feeders and Receivers can connect to multiple UDLs at the same 140 time, UDL network addresses SHOULD be unique among those UDLs to 141 allow Feeders and Receivers to distinguish UDLs. That is, UDL 142 network address space SHOULD be either a part of global address space 143 or a part of private address space that are well coordinated among 144 UDL service providers so that UDL IP addresses are uniquely 145 allocated. 147 The following subsections describe DTCP messages. State names used 148 in these subsections are the one used in the state transition diagram 149 in Section 4. 151 2.1 DTCP Announcement Message 153 The DTCP Announcement Message is periodically sent from a Feeder to 154 Receivers through a UDL. The roles of a DTCP Announcement Message 155 are: 156 - to notify the availability of a Feeder to Receivers. 157 - to give a clock to Receivers to determine a timing to send a DTCP 158 Tunnel Setup message to the Feeder. 159 - to announce Feeder's information that is necessary to send a DTCP 160 Request message. 162 A Feeder SHOULD send DTCP Announcement messages periodically if the 163 Feeder is working and a UDL is administratively available. The 164 interval rate SHOULD be notified in the interval field of this 165 message. The recommended interval rate is DTCP_ANN_INTERVAL. The 166 code field of this message indicates the availability of the Feeder 167 and tunnels. 169 If the code field of a DTCP Announcement message received by a 170 Receiver is DTCP_CODE_OK, it means the Feeder is available and a new 171 tunnel can be set up with the Feeder. If the Receiver does not have 172 a tunnel yet and the Receiver wants to have one, the Receiver can set 173 up a tunnel by using Tunnel Setup messages (See 2.2). If the 174 Receiver already has a tunnel with the Feeder, the Receiver can keep 175 using the tunnel and the UDL. If the valid time of a tunnel with the 176 UDL is almost expired, the Receiver can request to extend the valid 177 time of the tunnel. 179 If the code field of a DTCP Announcement message received by a 180 Receiver is DTCP_CODE_FULL, it means the Feeder is available but a 181 new tunnel cannot be setup no more with the Feeder at the moment. If 182 the Receiver does not have a tunnel yet and the Receiver wants to set 183 up a tunnel, the Receiver SHOULD wait for another DTCP Announcement 184 message with code value DTCP_CODE_OK. If the Receiver already has a 185 tunnel with the Feeder, the Receiver can keep using the tunnel and 186 the UDL. If the valid time of a tunnel with the UDL is almost 187 expired, the Receiver can request to extend the valid time of the 188 tunnel. 190 If the code field of a DTCP Announcement message received by a 191 Receiver is DTCP_CODE_GOINGDOWN, or the Receiver does not hear a DTCP 192 Announcement message from a Feeder for DTCP_ANN_TIMEOUT, it means the 193 Feeder is not available and tunnels should be released if the 194 Receiver has. If the Receiver wants to use the UDL, the Receiver 195 needs to establish a tunnel with other Feeder. 197 If the sequence field of a DTCP Announcement message received by a 198 Receiver changes more than expected, it means that the Feeder has 199 been booted without saving information of Recievers and tunnels. If 200 the Receiver wants to keep using UDL or to start to use UDL, the 201 Receiver needs to send a DTCP Tunnel Setup Request message to a 202 Feeder. 204 2.2. DTCP Tunnel Setup Messages 206 The DTCP Tunnel Setup messages consist of three messages: Request, 207 Reply, and Release. These messages are exchanged between a Feeder 208 and a Receiver through a BDL on demand. They have the same formats, 209 but op field has a different value for each message. 211 The roles of DTCP Tunnel Setup Messages are: 212 - to establish and to release a tunnel dynamically between a Feeder 213 and a Receiver. Recievere's UDL IP address can be allocated with 214 these messages in the case where the Receiver does not have a 215 statically allocated UDL IP address. 216 - to notify Receiver's node information that is necessary for 217 communication to a Feeder. (e.g. Receiver's MAC address) 219 The outline of the procedure follows. State names here are the state 220 transition diagram in Section 4. 222 0. A Receiver hears a DTCP Announcement message from a Feeder. (See 2.1) 223 Receiver's state becomes OPEN. 225 1. The Receiver sends a DTCP Request message to the Feeder. 226 Receiver's MAC address is carried on the DTCP options field if 227 necessary. Receiver's state becomes REQ_SENT. If Feeder 228 receives this message, Feeder's state for the Receiver becomes 229 REQ_RECV. A Feeder has a tunnel state per Receiver. 231 2. The Feeder sends back a DTCP Reply message to the Receiver. 232 If the request is accepted, the code field of the reply message 233 is DTCP_CODE_OK. The Feeder SHOULD configure the tunnel before 234 sending back the message. After the Receiver prepares for the 235 tunnel, the tunnel can be used. Both Feeder's state and 236 Receiver's state become ESTABLISHED. 237 at a Feeder: 238 - To avoid a flood of request messages to extend the valid 239 time of tunnels from Receivers, the valid time assigned 240 to each Receiver SHOULD be varied between 241 DTCP_TUN_VALIDTIME plus-minus DTCP_TUN_REFRESH. 242 If the Feeder does not want assign such a long period, 243 the period can be shorten, but with random variation 244 (plus-minus DTCP_TUN_REFRESH). If the Receiver wants to 245 be assigned shorter period than DTCP_TUN_VALIDTIME, there 246 is no need of variation. 247 at a Receiver: 248 - The Receiver SHOULD use the dynamically allocated UDL IP 249 address if allocated. 250 - The Receiver can send routing information only when the 251 Receiver is allowed to do it. 252 If the Receiver receives a reply message with its code value 253 DTCP_CODE_NO, or the Receiver does not get any response from a 254 Feeder, the Receiver should wait for another DTCP Announcement 255 message with code value DTCP_CODE_OK. Both Feeder's state and 256 Receiver's state becomes OPEN. 258 3. If the rest of valid time becomes less than DTCP_TUN_REFRESH, 259 the Receiver sends a DTCP Request message to the Feeder to extend 260 the valid time. By this request, the Receiver can extend the 261 valid time of both a tunnel and the dynamically assigned UDL IP 262 address at the same time. All fields including DTCP options of 263 the DTCP Request message SHOULD be filled as if it is a request 264 message when the Receiver has a statically allocated UDL IP 265 address. Receiver's state becomes REFRESHING, but Feeder's state 266 does not change from ESTABLISHED. 268 The Feeder sends back a DTCP Reply message. All fields including 269 DTCP options of the DTCP Reply message SHOULD be filled as if it 270 is a reply message to a request that is to set up a new tunnel. 271 If the Receiver does not receive any reply message, the Receiver 272 SHOULD wait for another DTCP Announcement message with code value 273 DTCP_CODE_OK. If the code field of the reply message is 274 DTCP_CODE_NO, it means the Receiver cannot extend the valid time 275 of the tunnel. After the valid time is expired, both the Feeder 276 and the Receiver unconfigure the tunnel, and MUST NOT keep using 277 the tunnel. 279 If the request is accepted, Receiver's state becomes ESTABLISHED. 280 If the request is denied, Receiver's state becomes NOREFRESH. 281 Feeder's state does not change in either case. 283 4. If a Receiver finishes using a tunnel, the Receiver sends a DTCP 284 release message to the Feeder to release the tunnel. Either 285 Feeder or Receiver can send a DTCP Release message first. The 286 tunnel between the Feeder and the Recever is released after the 287 exchange of DTCP Release messages between them. 289 - If a Receiver (or a Feeder) sends a DTCP Release message 290 first, its state becomes REL_WAIT. If the Receiver (or the 291 Feeder) does not receive a response release message, the 292 Receiver (or the Feeder) SHOULD send a DTCP Release message 293 again after a next DTCP Announcement message. After receiving 294 a response release message, its state becomes OPEN. 295 - If a Feeder (or a Receiver) receives a DTCP Release message 296 for an existing tunnel, the Feeder (or the Receiver) SHOULD 297 release the tunnel and send back a DTCP Release message. 298 Feeder's state becomes OPEN. 299 - If a Feeder or a Receiver receives a DTCP Release message 300 for an unknown tunnel, it SHOULD send back a DTCP Release 301 message for the unknown tunnel. 302 - If the releasing is successful, Both Feeder's state and 303 Receiver's state become OPEN. 305 3. The format of DTCP messages 307 DTCP is a protocol over UDP. Its port number is (TBD). 309 3.1. Announcement Message Format 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Op | Code | Interval | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Sequence |Pattern Length | RecvID type | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Pattern | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Feeder ID | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | UDL Netmask | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Feeder BDL IP addr | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | DTCP options... | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 src IP addr of the IP header: 328 - Feeder's UDL IP address 329 dst IP addr of the IP header: 331 - 255.255.255.255 (link-local broadcast address of IPv4) 332 dst port of the UDP header: 333 - (TBD) 335 Op: 336 0 = DTCP Announcement message 337 Code: 338 0 = DTCP_CODE_OK 339 This Feeder is active and new tunnels can be set up 340 with this Feeder. 341 1 = DTCP_CODE_FULL 342 This Feeder is active but new tunnels cannot be set 343 up with this Feeder. e.g. address pool is empty, 344 or a tunnel table is full. 345 2 = DTCP_CODE_GOINGDOWN 346 This Feeder will be down soon. 347 Interval: 348 - Interval time in second to send a DTCP Announcement 349 message. The recommended interval is DTCP_ANN_INTERVAL. 350 This field SHOULD not be changed during the Feeder 351 keeps sending DTCP Announcement messages. 352 Sequence: 353 - Sequence number of DTCP Announcemenet messages. 354 A Feeder SHOULD assign an initial random number when 355 it boots so that Receivers can recognize this Feeder' 356 rebooting from the big change of this field. 357 The next sequence number of 2^16-1 is 0. 358 Pattern: 359 - This field is to limit the number of Receivers that 360 can respond to a DTCP Announcemnet message to avoid 361 a flood of DTCP messages. Only Receivers who 362 satisfies following expression are allowed to respond. 363 (Reciever_ID) & MASK == pattern & MASK, 364 where MASK = (1 << Pattern_Length) - 1 365 - Unused pattern bits SHOULD be zero. 366 Pattern Length: 367 - See the explanation for pattern field. 368 RecvID type: (Receiver-ID type) 369 - See the explanation for pattern field. 370 0 = Receiver BDL IP address 371 1 = Receiver MAC address 372 Feeder ID: 373 - Identity information of the Feeder. This field will 374 be used to select a Feeder by Receivers. --(TBD)-- 375 UDL Netmask: 376 - the netmask of the UDL 377 Feeder BDL IP addr: 378 - Feeder BDL IP address 380 3.2. Request, Reply, Release Messages Format 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Op | Code | Valid Time | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Request Flags | Accept Flags | Tunnel Proto | Reserved | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | src UDL IP addr | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | dst UDL IP addr | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | DTCP options... | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 src IP addr of the IP header: 395 - Source node's BDL IP address 396 dst IP addr of the IP header: 397 - Destination node's BDL IP address 398 dst port of the UDP header: 399 - Default port number is (TBD). 401 Op: 402 8 = Request 403 - To request to establish a tunnel, to extend 404 the valid time of a tunnel, or to change the 405 parameters sent before. 406 - Known information SHOULD be put into fields. 407 9 = Reply 408 - To respond to a request message. 409 - Known information SHOULD be put into fields. 410 10 = Release 411 - To release a tunnel. 412 Code: 413 - In a Request message, MUST be zero. 414 - In a Reply message, 415 0 = DTCP_CODE_OK 416 The request is Accepted. 417 1 = DTCP_CODE_FULL 418 The request is denied, because tunnel is 419 unavailable, e.g. the address pool is empty, 420 or tunnel table is full. 421 2 = DTCP_CODE_NO 422 The request is denied because of 423 administrative reasons. 424 - In a Release message, MUST be zero. 426 Valid Time: 427 - Valid time of a tunnel in second. If Receiver's 428 UDL IP address is allocated dynamically, this field 429 also means its valid time. 430 - In a Request message, the source node puts a valid 431 time it wishes. Zero means source node does not 432 want to use tunnel no more. Zero would be used to 433 release tunnels gracefully. 434 - In a Reply message, the source node put a valid time 435 it allows. If the source node does not allow to use 436 a tunnel, this field MUST be zero. The source node 437 can tell longer period than the destination wishes, 438 especially when the destination wishes zero seconds. 439 - In a Release message, MUST be zero. 441 Request Flags: (Request flags from a source node) 442 Accept Flags: (Acceptable flags by a destination node) 443 - In a Release message, all bits MUST be zero. 444 - In a Request and a Reply message, each bit has 445 following meanings: 446 (R=Request Flags, A=AcceptFlags, MSB=7) 447 7: unicast routing info 448 - R: If source node wants to send unicast 449 routing information, then 1, else 0. 450 - A: If source node accepts unicast routing 451 information, then 1, else 0. 452 - If a node says 1 in R, and the opposite node 453 says 1 in A, then unicast routin information 454 can be sent in the direction. 455 6: multicast routing info 456 - R: If source node wants to send multicast 457 routing information, then 1, else 0. 458 - A: If source node accepts multicast routing 459 information, then 1, else 0 460 - If a node says 1 in R, and the opposite node 461 says 1 in A, then multicast routing information 462 can be sent in the direction. 463 5: IGMP (join, leave) 464 - R: If source node wants to send IGMP join/leave, 465 then 1, else 0. 466 - A: If source node accepts IGMP join/leave, 467 then 1, else 0. 468 - If a node says 1 in R, and the opposite node 469 says 1 in A, then IGMP join/leave can be 470 sent in the direction. 471 4: reserved: (MUST BE zero) 472 3: reserved: (MUST BE zero) 473 2: reserved: (MUST BE zero) 474 1: unnumbered or not 475 - R: If source node wants unnumbered tunnel, 476 then 1, else 0. 477 - A: reserved (MUST BE zero) 478 - If both nodes say 1, then the tunnel is 479 unnumbered. 480 0: TTL treatment in a tunnel 481 - R: If source node wants TTL field to be 482 decremented by the number of hops, then 1. 483 If source node wants TTL field to be 484 decremented only by 1, then 0. 485 - A: reserved (MUST BE zero) 486 - If both nodes say 1, then TTL is decremented 487 by the number of hops. 488 - If a node wants to change flags, the node sends a 489 Request message. 491 Tunnel Proto (Tunneling Protocol): 492 - Selected tunneling protocol. 493 - In a request message, if a node can support multiple 494 tunneling protocol, this field SHOULD be zero and a 495 candidates list SHOULD be appeared in DTCP options. 496 If a node can support only one tunneling protocol, 497 this field is filled with the protocol. 498 - If the opposite node sends a tunneling protocol list 499 in a DTCP options of a request message, this field 500 of a reply message should be filled with the 501 selected protocol. If any of the protocols are not 502 supported, the request SHOULD be rejected and this 503 field MUST be zero. 505 Reserved: 506 - (MUST BE zero) 508 src UDL IP addr: 509 - Source node's UDL IP address 510 - If source node knows its UDL IP address, this field 511 SHOULD be filled with the address. For example, 512 a UDL IP address is statically allocated, or it has 513 been already allocated dynamically by a previous request. 514 - If source node does not know its UDL IP address, 515 this field MUST be zero. For example, in the case 516 where requesting a UDL IP address in a Request message. 518 dst UDL IP addr: 519 - Destination node's UDL IP address 520 - If source node knows destination's UDL IP address, 521 this field SHOULD be filled with the address. 522 - If source node does not know destination's UDL IP 523 address, this field MUST be zero. For example, in 524 the case where notifying a failure of a tunnel setup 525 request by a Reply message. 527 DTCP options: 528 - All the options that was necessary to establish 529 tunnel SHOULD appear in all Request and Reply 530 messages. This would avoid troubles if opposite 531 side has been rebooted after last exchange of DTCP 532 messages. 534 3.3. DTCP options: 536 - No Operation 537 +-------+ 538 | type | 539 +-------+ 540 type: 0 = NoOp 542 - No Operation 543 +-------+-------+-------+-------+ 544 | type | len | padding... | 545 +-------+-------+-------+-------+ 546 type: 1 = NoOp, len = N 547 - padding MUST be zero. 549 - UDL Netmask 550 +-------+-------+ 551 | type | len | 552 +-------+-------+-------+-------+ 553 | UDL Netmask | 554 +-------+-------+-------+-------+ 555 type: 2 = UDL Netmask, len = 6 556 - to notify UDL Netmask. 558 - Acceptable Tunneling Protocol option 559 +-------+-------+-------+-------+ 560 | type | len |list of proto..| 561 +-------+-------+-------+-------+ 562 type: 3 = acceptable tunnel proto, len = N 563 - To notify acceptable tunneling protocol. Protocols are 564 listed in the order of precedence. 565 - Each protocol is denoted by 1 byte. 566 - 1: ipproto=4 (IP in IP) 567 - 2: ipproto=94, raw packet format (IP within IP) 568 - Selected protocol is notified by using the tunnel protocol 569 field of DTCP Tunnel Setup messages. 571 - Authentication option (Certification?) 572 +-------+-------+-------+-------+ 573 | type | len | ........ | 574 +-------+-------+-------+-------+ 575 type: 4 = authentication info, len = N 576 - (TBD) 577 - basic authentication 578 - otp 579 - etc. 581 - Source node's MAC address 582 +-------+-------+-------+-------+ 583 | type | len | MAC(high) | 584 +-------+-------+-------+-------+ 585 | MAC(low) | 586 +-------+-------+-------+-------+ 587 type: 5 = src MAC addr, len = 8 588 - to notify source node's MAC address (or EUI-48). 589 - Typically, to notify Receiver's MAC address to a Feeder. 591 4. State Transition Diagram 593 State Transition Diagram for DTCP Tunnel Setup Messages: 594 (Event/Action style) 595 +-------------+ ---+ REQ0/REL 596 | CLOSED | | REL/REL 597 +-------------+ <--+ 598 A 599 | 600 V 601 +-------------+ 602 +--------------------->| OPEN |<---------------------------+ 603 | +-------------+ | 604 | / \ | 605 | / \ | 606 | /(Next+wait) \REQUEST/[C] | 607 | / /REQUEST \ | 608 | / \ | 609 |(LinkDown), v v | 610 |NO/ +-----------+ REQUEST/ +-----------+ | 611 +<----------| REQ_SENT |---------->| REQ_RECV | | 612 | +-----------+ +-----------+ | 613 | A | \ / | 614 | | V \ / | 615 | +---+ \ / | 616 | (Next+wait)/REQ \ / | 617 | \ / | 618 +-----------+ ---+(Next+wait) | | | 619 | REL_WAIT | |/REL |OK/ |/OK | 620 +-----------+ <--+ | | | 621 A | | RELEASE/RELEASE |[!T] 622 |[!T] |[T] |[T] +------------------------>+ 623 | | | / | 624 |(LinkDown),REQ0, v v / | 625 |(EndOfComm)/RELEASE +-------------+ ---+ | 626 +<---------------------| ESTABLISHED | |REQUEST/OKorNO | 627 | +-------------+ <--+ | 628 | A | | 629 | |(VT>x), |(ValidTime+ 638 |(ValidTime==0), | v | 639 |(EndOfComm)/RELEASE +-------------+ RELEASE/RELEASE | 640 +<---------------------| NOREFRESH |--------------------------->+ 641 +-------------+ 643 Next: DTCP Announcemenet with DTCP_CODE_OK 644 wait: random wait 645 LinkDown: TimeOut or DTCP Announcement with DTCP_CODE_GOINGDOWN 647 [T]: Tunnel up 648 [!T]: Tunnel down 649 [C]: check whether the request is acceptable 651 5. Recommended constant values or expressions 653 DTCP_ANN_INTERVAL: 10 (sec) 654 - Interval time of sending DTCP Announcement messages 656 DTCP_ANN_WAIT: interval / 2 (5 sec by default) 657 - The maximum waiting time to respond after receiving a DTCP 658 Announcement message. 660 DTCP_ANN_TIMEOUT: interval * 6 (60 sec by default) 661 - The valid time of a DTCP Announcement message. 663 DTCP_TUN_VALIDTIME: 1200 (sec) (= interval * 120) 664 - Tunnel valid time. 666 DTCP_TUN_REFRESH: interval * 12 (120 sec by default) 667 - Threshold value to start extending tunnel valid time. 669 Security Considerations 671 Security issues are not discussed in this document. 673 Acknowledgements 675 The concept and the basic design of DTCP is a result of discussions 676 by the members of Wish-WG of WIDE Project. Noboru Fujii and Mikiyo 677 Nishida give members technical valuable input from their independent 678 experience of implementation. Hitoshi Asaeda, Akira Kato, Kazuhiro 679 Hara, Jun Takei, and Akihiro Tosaka give members technical valuable 680 comments. 682 References 684 [1] H. Izumiyama, A. Tosaka, A. Kato, 685 "An IP tunneling approach for Uni-directional Link routing", 686 , Nov 1997 688 [2] H. Izumiyama, A. Tosaka, 689 "Dynamic Tunneling Path Configuration for Uni-directional Link Routing", 690 , Nov 1997 692 Authors Information 694 Noritoshi Demizu 695 Sony Computer Science Laboratory, Inc. 696 Takanawa Muse Bldg. 697 3-14-13, Higashigotanda, 698 Shinagawa-ku, Tokyo, 141 Japan 699 Phone: +81-3-5448-4380 700 E-mail: demizu@csl.sony.co.jp 701 E-mail: nori-d@is.aist-nara.ac.jp 703 Hidetaka Izumiyama 704 Japan Satellite Systems Inc. 705 Toranomon 17 Mori Bldg.5F 706 1-26-5 Toranomon, 707 Minato-ku, Tokyo 105 Japan 708 Phone: +81-3-5511-7568 709 Fax: +81-3-5512-7181 710 E-mail: izu@jcsat.co.jp