idnits 2.17.1 draft-ietf-forces-sctptml-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3654], [RFC2960], [FE-PROTO]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 222: '... The TML SHOULD will be able to ...' RFC 2119 keyword, line 415: '... delivered but MUST at the same time...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 9, 2007) is 6012 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) == Missing Reference: 'RFC3768' is mentioned on line 454, but not defined ** Obsolete undefined reference: RFC 3768 (Obsoleted by RFC 5798) == Unused Reference: 'RFC2434' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'FE-MODEL' is defined on line 512, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hadi Salim 3 Internet-Draft ZNYX Networks 4 Expires: May 12, 2008 K. Ogawa 5 NTT Network Service Systems 6 Laboratories 7 November 9, 2007 9 SCTP based TML (Transport Mapping Layer) for ForCES protocol 10 draft-ietf-forces-sctptml-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 This Internet-Draft will expire on May 12, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines the SCTP based TML (Transport Mapping Layer) 44 for the ForCES protocol. It explains the rationale for choosing the 45 SCTP (Stream Control Transmission Protocol) [RFC2960] and also 46 describes how this TML addresses all the requirements described in 47 [RFC3654] and the ForCES protocol [FE-PROTO] draft. 49 Table of Contents 51 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 54 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. The TML layer . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2.1. TML Parameterization . . . . . . . . . . . . . . . . . 6 57 3.3. The TML-PL interface . . . . . . . . . . . . . . . . . . . 6 58 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7 59 4.1. Introduction to SCTP . . . . . . . . . . . . . . . . . . . 7 60 4.2. Rationale for using SCTP for TML . . . . . . . . . . . . . 9 61 4.3. Meeting TML requirements . . . . . . . . . . . . . . . . . 9 62 4.3.1. Reliability . . . . . . . . . . . . . . . . . . . . . 10 63 4.3.2. Congestion control . . . . . . . . . . . . . . . . . . 10 64 4.3.3. Timeliness and prioritization . . . . . . . . . . . . 10 65 4.3.4. Addressing . . . . . . . . . . . . . . . . . . . . . . 10 66 4.3.5. HA . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3.6. DOS prevention . . . . . . . . . . . . . . . . . . . . 11 68 4.3.7. Encapsulation . . . . . . . . . . . . . . . . . . . . 11 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 7. Manageability Considerations . . . . . . . . . . . . . . . . . 11 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Intellectual Property and Copyright Statements . . . . . . . . . . 14 79 1. Definitions 81 The following definitions are taken from [RFC3654]and [RFC3746]: 83 ForCES Protocol -- The protocol used at the Fp reference point in the 84 ForCES Framework in [RFC3746]. 86 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 87 architecture that defines the ForCES protocol architecture and the 88 state transfer mechanisms as defined in [FE-PROTO]. 90 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 91 ForCES protocol architecture that specifically addresses the protocol 92 message transportation issues, such as how the protocol messages are 93 mapped to different transport media (like TCP, IP, ATM, Ethernet, 94 etc), and how to achieve and implement reliability, multicast, 95 ordering, etc. 97 2. Introduction 99 The ForCES (Forwarding and Control Element Separation) working group 100 in the IETF is defining the architecture and protocol for separation 101 of control and forwarding elements in network elements such as 102 routers. [RFC3654] and [RFC3746] respectively define architectural 103 and protocol requirements for the communication between CE and FE. 104 The ForCES protocol layer specification [FE-PROTO] describes the 105 protocol semantics and workings. The ForCES protocol layer operates 106 on top of an inter-connect hiding layer known as the TML. The 107 relationship is illustrated in Figure 1. 109 This document defines the SCTP based TML for the ForCES protocol 110 layer. It also addresses all the requirements for the TML including 111 security, reliability, etc as defined in [FE-PROTO]. 113 3. Protocol Framework Overview 115 The reader is referred to the Framework document [RFC3746], and in 116 particular sections 3 and 4, for an architectural overview and 117 explanation of where and how the ForCES protocol fits in. 119 There is some content overlap between the ForCES protocol draft 120 [FE-PROTO] and this section in order to provide clarity. 122 The ForCES layout constitutes two pieces: the PL and TML layer. This 123 is depicted in Figure 1. 125 +---------------------------------------------- 126 | CE PL | 127 +---------------------------------------------- 128 | CE TML | 129 +---------------------------------------------- 130 ^ 131 | 132 ForCES | (i.e. Forces data + control 133 PL | packets ) 134 messages | 135 over | 136 specific | 137 TML | 138 encaps | 139 and | 140 transport | 141 | 142 v 143 +------------------------------------------------ 144 | FE TML | 145 +------------------------------------------------ 146 | FE PL | 147 +------------------------------------------------ 149 Figure 1: Message exchange between CE and FE to establish an NE 150 association 152 The PL layer is in charge of the ForCES protocol. Its semantics and 153 message layout are defined in [FE-PROTO]. The TML Layer is necessary 154 to connect two ForCES PL layers as shown in Figure 1. 156 Both the PL and TML are standardized by the IETF. While only one PL 157 is defined, different TMLs are expected to be standardized. The TML 158 at each of the peers (CE and FE) is expected to be of the same 159 definition in order to inter-operate. 161 When transmitting, the PL delivers its messages to the TML. The TML 162 then delivers the PL message to the destination peer TML(s) as 163 defined by the addressing in the PL message. 165 On reception of a message, the TML delivers the message to its 166 destination PL layer(s). 168 3.1. The PL 170 The PL is common to all implementations of ForCES and is standardized 171 by the IETF [FE-PROTO]. The PL layer is responsible for associating 172 an FE or CE to an NE. It is also responsible for tearing down such 173 associations. An FE uses the PL layer to throw various subscribed-to 174 events to the CE PL layer as well as respond to various status 175 requests issued from the CE PL. The CE configures both the FE and 176 associated LFBs attributes using the PL layer. In addition the CE 177 may send various requests to the FE to activate or deactivate it, 178 reconfigure its HA parameterization, subscribe to specific events 179 etc. 181 3.2. The TML layer 183 The TML layer is responsible for transport of the PL layer messages. 184 The TML provides the following services on behalf of the ForCES 185 protocol: 187 1. Reliability 188 As defined by RFC 3654, section 6 #6. 190 2. Security 191 TML provides security services to the ForCES PL. The TML 192 definition needs to define how the following are achieved: 194 * Endpoint authentication of FE and CE 196 * Message authentication 198 * Confidentiality service 200 3. Congestion Control 201 The congestion control mechanism defined by the TML should 202 prevent the FE from being overloaded by the CE. Additionally, 203 the circumstances under which notification is sent to the PL to 204 notify it of congestion must be defined. 206 4. Uni/multi/broadcast addressing/delivery, if any 207 If there is any mapping between PL and TML level uni/multi/ 208 broadcast addressing it needs to be defined. 210 5. Transport High Availability 211 It is expected that availability of transport links is the TML's 212 responsibility. However, on config basis, the PL layer may wish 213 to participate in link failover schemes and therefore the TML 214 must allow for this. 216 6. Encapsulations used 217 Different types of TMLs will encapsulate the PL messages on 218 different types of headers. The TML needs to specify the 219 encapsulation used. 221 7. Prioritization 222 The TML SHOULD will be able to handle up to 8 priority levels 223 needed by the PL and will provide preferential treatment. 224 The TML needs to define how this is achieved. 226 8. Protection against DoS attacks 227 As described in the Requirements RFC 3654, section 6 229 It is expected more than one TML will be standardized. The different 230 TMLs each could implement things differently based on capabilities of 231 underlying media and transport. However, since each TML is 232 standardized, interoperability is guaranteed as long as both 233 endpoints support the same TML. 235 3.2.1. TML Parameterization 237 It is expected that it should be possible to use a configuration 238 reference point, such as the FEM or the CEM, to configure the TML. 240 Some of the configured parameters may include: 242 o PL ID 244 o Connection Type and associated data. For example if a TML uses 245 IP/TCP/UDP then parameters such as TCP and UDP ports and IP 246 addresses need to be configured. 248 o Number of transport connections 250 o Connection Capability, such as bandwidth, etc. 252 o Allowed/Supported Connection QoS policy (or Congestion Control 253 Policy) 255 3.3. The TML-PL interface 257 [TML-API] defines an interface between the PL and the TML layers. 258 The end goal of [TML-API] is to provide a consistent top edge 259 semantics for all TMLs to adhere to. Conforming to such an interface 260 makes it easy to plug in different TMLs over time. It also allows 261 for simplified TML parameterization requirement stated in 262 Section 3.2.1. 264 ,''''''''''''''''''''''| 265 | | 266 | PL Layer | 267 | | 268 |........ .............| 269 ^ 270 | 271 | TML API 272 | 273 | 274 V 275 ,''''''''''''''''''''''`. 276 | | 277 | TML Layer | 278 | | 279 '`''''''''''''''''''''''' 281 Figure 2: The TML-PL interface 283 We are going to assume the existence of such an interface and not 284 discuss it further. The reader is encouraged to read [TML-API] as a 285 background. 287 4. SCTP TML overview 289 4.1. Introduction to SCTP 291 SCTP [RFC2960] is an end-to-end transport protocol that is equivalent 292 to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP 293 can do most of what UDP, TCP, or DCCP can achieve. SCTP as well can 294 do most of what a combination of the other transport protocols can 295 achieve (eg TCP and DCCP or TCP and UDP). 297 Like TCP, it provides ordered, reliable, connection-oriented, flow- 298 controlled, congestion controlled data exchange. Unlike TCP, it does 299 not provide byte streaming and instead provides message boundaries. 301 Like UDP, it can provide unreliable, unordered data exchange. Unlike 302 UDP, it does not provide multicast support 304 Like DCCP, it can provide unreliable, ordered, congestion controlled, 305 connection-oriented data exchange. 307 SCTP also provides other services that none of the 3 transport 308 protocols mentioned above provide. These include: 310 o Multi-homing 311 An SCTP connection can make use of multiple destination IP 312 addresses to communicate with its peer. 314 o Runtime IP address binding 315 With the SCTP ADDIP feature, a new address can be bound at 316 runtime. This allows for migration of endpoints without 317 restarting the association (valuable for high availability). 319 o A range of reliability shades with congestion control 320 SCTP offers a range of services from full reliability to none, and 321 from full ordering to none. With SCTP, on a per message basis, 322 the application can specify a message's time-to-live. When the 323 expressed time expires, the message can be "skipped". 325 o Built-in heartbeats 326 SCTP has built-in heartbeat mechanism that validate the 327 reachability of peer addresses. 329 o Multi-streaming 330 A known problem with TCP is head of line (HOL) blocking. If you 331 have independent messages, TCP enforces ordering of such messages. 332 Loss at the head of the messages implies delays of delivery of 333 subsequent packets. SCTP allows for defining upto 64K independent 334 streams over the same socket connection, which are ordered 335 independently. 337 o Message boundaries with reliability 338 SCTP allows for easier message parsing (just like UDP but with 339 reliability built in) because it establishes boundaries on a PL 340 message basis. On a TCP stream, one would have to peek into the 341 message to figure the boundaries. 343 o Improved SYN DOS protection 344 Unlike TCP, which does a 3 way connection setup handshake, SCTP 345 does a 4 way handshake. This improves against SYN-flood attacks 346 because listening sockets do not set up state until a connection 347 is validated. 349 o Simpler transport events 350 An application (such as the TML) can subscribe to be notified of 351 both local and remote transport events. Events such as indication 352 of association changes, addressing changes, remote errors, expiry 353 of timed messages, etc, are off by default and require explicit 354 subscription. 356 o Simplified replicasting 357 Although SCTP does not allow for multicasting it allows for a 358 single message from an application to be sent to multiple peers. 359 This reduces the messaging that typically crosess different memory 360 domains within a host. 362 4.2. Rationale for using SCTP for TML 364 SCTP has all the features required to provide a robust TML. As a 365 transport that is all-encompassing, it negates the need for having 366 multiple transport protocols, as has been suggested so far in the 367 other proposals for TMLs. As a result it allows for simpler coding 368 and therefore reduces a lot of the interoperability concerns. 370 SCTP is also very mature and widely deployed completing the equation 371 that makes it a superior choice in comparison with other proposed 372 TMLs. 374 4.3. Meeting TML requirements 376 ,''''''''''''''''''''| 377 | | 378 | PL | 379 | | 380 |........ .+.........| 381 | 382 + TML API 383 | 384 ,''''''''''+'''''''''`. 385 | | 386 | TML | 387 | | 388 '`'''''''''+''''''''''' 389 | 390 + SCTP socket API 391 | 392 ,''''''''''+'''''''''`. 393 | | 394 | SCTP | 395 | (over IP) | 396 | | 397 '`''''''''''''''''''''' 399 Figure 3: The TML-SCTP interface 401 Figure 3 above shows the interfacing between the TML and SCTP. There 402 is only one socket connection open with two streams used. The first 403 stream which is high priority will be dedicated for configuration 404 data and the second lower priority stream is used for data path 405 redirect. The TML will use information passed by the TML API to 406 select which of the two streams to use when sending. The TML will 407 also subscribe to events from SCTP associated with the two streams. 409 4.3.1. Reliability 411 As mentioned earlier, a shade of reliability ranges is possible in 412 SCTP. Therefore this requirement is met. 414 Redirected control traffic in ForCES is not expected to be reliably 415 delivered but MUST at the same time be congestion aware. This 416 requirement is also met by SCTP. 418 4.3.2. Congestion control 420 Congestion control is built into SCTP. Therefore, this requirement 421 is met. 423 4.3.3. Timeliness and prioritization 425 By using multiple streams in conjunction with the partial-reliability 426 feature, both timeliness and prioritization can be achieved. 428 4.3.4. Addressing 430 SCTP can be told to replicast packets to multiple destinations. The 431 TML will translate PL level addresses, to a variety of unicast IP 432 addresses in order to emulate multicast and broadcast. Note, 433 however, unlike other proposed TMLs, that there are no extra headers 434 required for SCTP. 436 4.3.5. HA 438 Transport link resiliency is SCTP's strongest point (where it totally 439 outclasses all other TML proposals). Failure detection and recovery 440 is built in as mentioned earlier. 442 o The SCTP multi-homing feature is used to provide path diversity. 443 Should one of the peer IP addresses become unreachable, the 444 other(s) are used without needing lower layer convergence 445 (routing, for example) or even the TML becoming aware. 447 o SCTP heartbeats and data transmission thresholds are used on a per 448 peer IP address to detect reachability faults. The faults could 449 be a result of an unreachable address or peer, which may be caused 450 by a variety of reasons, like interface, network, or endpoint 451 failures. The cause of the fault is noted. 453 o With the ADDIP feature, one can migrate IP addresses to other 454 nodes at runtime. This is not unlike the VRRP[RFC3768] protocol 455 use. This feature is used in addition to multi-homing in a 456 planned migration of activity from one FE/CE to another. In such 457 a case, part of the provisioning recipe at the CE for replacing an 458 FE involves migrating activity of one FE to another. 460 4.3.6. DOS prevention 462 Two separate streams are used within any FE-CE setup: the higher 463 priority one is for configuration and the lower priority one for data 464 redirection. The design is strict priority to further guarantee that 465 lower priority is starved if lack of resources happen. 467 4.3.7. Encapsulation 469 There is no extra encapsulation added by this TML. SCTP provides for 470 extensions to be added to it by defining new chunks. In the future, 471 should the need arise, a new SCTP extension can be defined to meet 472 newer ForCES requirements. 474 5. IANA Considerations 476 This document makes no request of IANA. 478 Note to RFC Editor: this section may be removed on publication as an 479 RFC. 481 6. Security Considerations 483 TBA: how to use TLS,IPSEC 485 7. Manageability Considerations 487 TBA 489 8. Acknowledgements 491 9. References 492 9.1. Normative References 494 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 495 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 496 October 1998. 498 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 499 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 500 Zhang, L., and V. Paxson, "Stream Control Transmission 501 Protocol", RFC 2960, October 2000. 503 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 504 of IP Control and Forwarding", RFC 3654, November 2003. 506 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 507 "Forwarding and Control Element Separation (ForCES) 508 Framework", RFC 3746, April 2004. 510 9.2. Informative References 512 [FE-MODEL] 513 Halpern, J. and E. Deleganes, "ForCES Forwarding Element 514 Model", Oct. 2007. 516 [FE-PROTO] 517 Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., 518 Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. 519 Gopal, "ForCES Protocol Specification", July 2007. 521 [TML-API] M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES 522 Transport Mapping Layer (TML) Service Primitives", 523 Feb. 2007. 525 Authors' Addresses 527 Jamal Hadi Salim 528 ZNYX Networks 529 Ottawa, Ontario 530 Canada 532 Email: hadi@znyx.com 533 Kentaro Ogawa 534 NTT Network Service Systems Laboratories 535 3-9-11 Midori-cho 536 Musashino-shi, Tokyo 180-8585 537 Japan 539 Email: ogawa.kentaro@lab.ntt.co.jp 541 Full Copyright Statement 543 Copyright (C) The IETF Trust (2007). 545 This document is subject to the rights, licenses and restrictions 546 contained in BCP 78, and except as set forth therein, the authors 547 retain all their rights. 549 This document and the information contained herein are provided on an 550 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 551 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 552 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 553 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 554 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 555 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 557 Intellectual Property 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org. 581 Acknowledgment 583 Funding for the RFC Editor function is provided by the IETF 584 Administrative Support Activity (IASA).