idnits 2.17.1 draft-hadi-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 537. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 218: '... The TML SHOULD will be able to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 18, 2006) is 6515 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) == Unused Reference: 'RFC2434' is defined on line 475, but no explicit reference was found in the text == Unused Reference: 'FE-MODEL' is defined on line 493, 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: 9 errors (**), 0 flaws (~~), 4 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: December 20, 2006 June 18, 2006 6 SCTP based TML (Transport Mapping Layer) for ForCES protocol 7 draft-hadi-forces-sctptml-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 20, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines the SCTP based TML (Transport Mapping Layer) 41 for the ForCES protocol. It explains the rationale for choosing the 42 SCTP (Stream Control Transmission Protocol) [RFC2960] and also 43 describes how this TML addresses all the requirements described in 44 [RFC3654] and the ForCES protocol [FE-PROTO] draft. 46 Table of Contents 48 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 51 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. The TML layer . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2.1. TML Parameterization . . . . . . . . . . . . . . . . . 6 54 3.3. The TML-PL interface . . . . . . . . . . . . . . . . . . . 6 55 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7 56 4.1. Introduction to SCTP . . . . . . . . . . . . . . . . . . . 7 57 4.2. Rationale for using SCTP for TML . . . . . . . . . . . . . 9 58 4.3. Meeting TML requirements . . . . . . . . . . . . . . . . . 9 59 4.3.1. Reliability . . . . . . . . . . . . . . . . . . . . . 10 60 4.3.2. Congestion control . . . . . . . . . . . . . . . . . . 10 61 4.3.3. Timeliness and prioritization . . . . . . . . . . . . 10 62 4.3.4. Addressing . . . . . . . . . . . . . . . . . . . . . . 10 63 4.3.5. HA . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.3.6. DOS prevention . . . . . . . . . . . . . . . . . . . . 11 65 4.3.7. Encapsulation . . . . . . . . . . . . . . . . . . . . 11 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Intellectual Property and Copyright Statements . . . . . . . . . . 14 75 1. Definitions 77 The following definitions are taken from [RFC3654]and [RFC3746]: 79 ForCES Protocol -- The protocol used at the Fp reference point in the 80 ForCES Framework in [RFC3746]. 82 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 83 architecture that defines the ForCES protocol architecture and the 84 state transfer mechanisms as defined in [FE-PROTO]. 86 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 87 ForCES protocol architecture that specifically addresses the protocol 88 message transportation issues, such as how the protocol messages are 89 mapped to different transport media (like TCP, IP, ATM, Ethernet, 90 etc), and how to achieve and implement reliability, multicast, 91 ordering, etc. 93 2. Introduction 95 The ForCES (Forwarding and Control Element Separation) working group 96 in the IETF is defining the architecture and protocol for separation 97 of control and forwarding elements in network elements such as 98 routers. [RFC3654] and [RFC3746] respectively define architectural 99 and protocol requirements for the communication between CE and FE. 100 The ForCES protocol layer specification [FE-PROTO] describes the 101 protocol semantics and workings. The ForCES protocol layer operates 102 on top of an inter-connect hiding layer known as the TML. The 103 relationship is illustrated in Figure 1. 105 This document defines the SCTP based TML for the ForCES protocol 106 layer. It also addresses all the requirements for the TML including 107 security, reliability, etc as defined in [FE-PROTO]. 109 3. Protocol Framework Overview 111 The reader is referred to the Framework document [RFC3746], and in 112 particular sections 3 and 4, for an architectural overview and 113 explanation of where and how the ForCES protocol fits in. 115 There may be some content overlap between the ForCES protocol draft 116 [FE-PROTO] and this section in order to provide clarity. 118 The ForCES layout constitutes two pieces: the PL and TML layer. This 119 is depicted in Figure 1. 121 +---------------------------------------------- 122 | CE PL | 123 +---------------------------------------------- 124 | CE TML | 125 +---------------------------------------------- 126 ^ 127 | 128 ForCES | (i.e. Forces data + control 129 PL | packets ) 130 messages | 131 over | 132 specific | 133 TML | 134 encaps | 135 and | 136 transport | 137 | 138 v 139 +------------------------------------------------ 140 | FE TML | 141 +------------------------------------------------ 142 | FE PL | 143 +------------------------------------------------ 145 Figure 1: Message exchange between CE and FE to establish an NE 146 association 148 The PL layer is in charge of the ForCES protocol. Its semantics and 149 message layout are defined in [FE-PROTO]. The TML Layer is necessary 150 to connect two ForCES PL layers as shown in Figure 1. 152 Both the PL and TML are standardized by the IETF. While only one PL 153 is defined, different TMLs are expected to be standardized. The TML 154 at each of the peers (CE and FE) is expected to be of the same 155 definition in order to inter-operate. 157 When transmitting, the PL delivers its messages to the TML. The TML 158 then delivers the PL message to the destination peer TML(s) as 159 defined by the addressing in the PL message. 161 On reception of a message, the TML delivers the message to its 162 destination PL layer(s). 164 3.1. The PL 166 The PL is common to all implementations of ForCES and is standardized 167 by the IETF [FE-PROTO]. The PL layer is responsible for associating 168 an FE or CE to an NE. It is also responsible for tearing down such 169 associations. An FE uses the PL layer to throw various subscribed-to 170 events to the CE PL layer as well as respond to various status 171 requests issued from the CE PL. The CE configures both the FE and 172 associated LFBs attributes using the PL layer. In addition the CE 173 may send various requests to the FE to activate or deactivate it, 174 reconfigure its HA parameterization, subscribe to specific events 175 etc. 177 3.2. The TML layer 179 The TML layer is responsible for transport of the PL layer messages. 180 The TML provides the following services on behalf of the ForCES 181 protocol: 183 1. Reliability 184 As defined by RFC 3654, section 6 #6. 186 2. Security 187 TML provides security services to the ForCES PL. The TML 188 definition needs to define how the following are achieved: 190 * Endpoint authentication of FE and CE 192 * Message authentication 194 * Confidentiality service 196 3. Congestion Control 197 The congestion control mechanism defined by the TML should 198 prevent the FE from being overloaded by the CE. Additionally, 199 the circumstances under which notification is sent to the PL to 200 notify it of congestion must be defined. 202 4. Uni/multi/broadcast addressing/delivery, if any 203 If there is any mapping between PL and TML level uni/multi/ 204 broadcast addressing it needs to be defined. 206 5. Transport High Availability 207 It is expected that availability of transport links is the TML's 208 responsibility. However, on config basis, the PL layer may wish 209 to participate in link failover schemes and therefore the TML 210 must allow for this. 212 6. Encapsulations used 213 Different types of TMLs will encapsulate the PL messages on 214 different types of headers. The TML needs to specify the 215 encapsulation used. 217 7. Prioritization 218 The TML SHOULD will be able to handle up to 8 priority levels 219 needed by the PL and will provide preferential treatment. 220 The TML needs to define how this is achieved. 222 8. Protection against DoS attacks 223 As described in the Requirements RFC 3654, section 6 225 It is expected more than one TML will be standardized. The different 226 TMLs each could implement things differently based on capabilities of 227 underlying media and transport. However, since each TML is 228 standardized, interoperability is guaranteed as long as both 229 endpoints support the same TML. 231 3.2.1. TML Parameterization 233 It is expected that it should be possible to use a configuration 234 reference point, such as the FEM or the CEM, to configure the TML. 236 Some of the configured parameters may include: 238 o PL ID 240 o Connection Type and associated data. For example if a TML uses 241 IP/TCP/UDP then parameters such as TCP and UDP ports and IP 242 addresses need to be configured. 244 o Number of transport connections 246 o Connection Capability, such as bandwidth, etc. 248 o Allowed/Supported Connection QoS policy (or Congestion Control 249 Policy) 251 3.3. The TML-PL interface 253 [TML-API] defines an interface between the PL and the TML layers. 254 The end goal of [TML-API] is to provide a consistent top edge 255 semantics for all TMLs to adhere to. Conforming to such an interface 256 makes it easy to plug in different TMLs over time. It also allows 257 for simplified TML parameterization requirement stated in 258 Section 3.2.1. 260 ,''''''''''''''''''''''| 261 | | 262 | PL Layer | 263 | | 264 |........ .............| 265 ^ 266 | 267 | TML API 268 | 269 | 270 V 271 ,''''''''''''''''''''''`. 272 | | 273 | TML Layer | 274 | | 275 '`''''''''''''''''''''''' 277 Figure 2: The TML-PL interface 279 We are going to assume the existence of such an interface and not 280 discuss it further. The reader is encouraged to read [TML-API] as a 281 background. 283 4. SCTP TML overview 285 4.1. Introduction to SCTP 287 SCTP [RFC2960] is an end-to-end transport protocol that is equivalent 288 to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP 289 can do most of what UDP, TCP, or DCCP can achieve. 291 Like TCP, it provides ordered, reliable, connection-oriented, flow- 292 controlled, congestion controlled data exchange. Unlike TCP, it does 293 not provide byte streaming and instead provides message boundaries. 295 Like UDP, it can provide unreliable, unordered data exchange. Unlike 296 UDP, it does not provide multicast support 298 Like DCCP, it can provide unreliable, ordered, congestion controlled, 299 connection-oriented data exchange. 301 SCTP also provides other services that none of the 3 transport 302 protocols mentioned above provide. These include: 304 o Multi-homing 305 An SCTP connection can make use of multiple destination IP 306 addresses to communicate with its peer. 308 o Runtime IP address binding 309 With the SCTP ADDIP feature, a new address can be bound at 310 runtime. This allows for migration of endpoints without 311 restarting the association (valuable for high availability). 313 o A range of reliability shades with congestion control 314 SCTP offers a range of services from full reliability to none, and 315 from full ordering to none. With SCTP, on a per message basis, 316 the application can specify a message's time-to-live. When the 317 expressed time expires, the message can be "skipped". 319 o Built-in heartbeats 320 SCTP has built-in heartbeat mechanism that validate the 321 reachability of peer addresses. 323 o Multi-streaming 324 A known problem with TCP is head of line (HOL) blocking. If you 325 have independent messages, TCP enforces ordering of such messages. 326 Loss at the head of the messages implies delays of delivery of 327 subsequent packets. SCTP allows for defining upto 64K independent 328 streams over the same socket connection, which are ordered 329 independently. 331 o Message boundaries with reliability 332 SCTP allows for easier message parsing (just like UDP but with 333 reliability built in) because it establishes boundaries on a PL 334 message basis. On a TCP stream, one would have to peek into the 335 message to figure the boundaries. 337 o Improved SYN DOS protection 338 Unlike TCP, which does a 3 way connection setup handshake, SCTP 339 does a 4 way handshake. This improves against SYN-flood attacks 340 because listening sockets do not set up state until a connection 341 is validated. 343 o Simpler transport events 344 An application (such as the TML) can subscribe to be notified of 345 both local and remote transport events. Events such as indication 346 of association changes, addressing changes, remote errors, expiry 347 of timed messages, etc, are off by default and require explicit 348 subscription. 350 o Simplified replicasting 351 Although SCTP does not allow for multicasting it allows for a 352 single message from an application to be sent to multiple peers. 353 This reduces the messaging that typically crosess different memory 354 domains within a host. 356 4.2. Rationale for using SCTP for TML 358 SCTP has all the features required to provide a robust TML. As a 359 transport that is all-encompassing, it negates the need for having 360 multiple transport protocols, as has been suggested so far in the 361 other proposals for TMLs. As a result it allows for simpler coding 362 and therefore reduces a lot of the interoperability concerns. 364 SCTP is also very mature and widely deployed completing the equation 365 that makes it a superior choice in comparison with other proposed 366 TMLs. 368 4.3. Meeting TML requirements 370 ,''''''''''''''''''''| 371 | | 372 | PL | 373 | | 374 |........ .+.........| 375 | 376 + TML API 377 | 378 ,''''''''''+'''''''''`. 379 | | 380 | TML | 381 | | 382 '`'''''''''+''''''''''' 383 | 384 + SCTP socket API 385 | 386 ,''''''''''+'''''''''`. 387 | | 388 | SCTP | 389 | (over IP) | 390 | | 391 '`''''''''''''''''''''' 393 Figure 3: The TML-SCTP interface 395 Figure 3 above shows the interfacing between the TML and SCTP. There 396 is only one socket connection open with two streams used. The first 397 stream which is high priority will be dedicated for configuration 398 data and the second lower priority stream is used for data path 399 redirect. The TML will use information passed by the TML API to 400 select which of the two streams to use when sending. The TML will 401 also subscribe to events from SCTP associated with the two streams. 403 4.3.1. Reliability 405 As mentioned earlier, a shade of reliability ranges is possible in 406 SCTP. Therefore this requirement is met. 408 4.3.2. Congestion control 410 Congestion control is built into SCTP. Therefore, this requirement 411 is met. 413 4.3.3. Timeliness and prioritization 415 By using multiple streams in conjunction with the partial-reliability 416 feature, both timeliness and prioritization can be achieved. 418 4.3.4. Addressing 420 SCTP can be told to replicast packets to multiple destinations. The 421 TML will translate PL level addresses, to a variety of unicast IP 422 addresses in order to emulate multicast and broadcast. Note, 423 however, that there are no extra headers required. 425 4.3.5. HA 427 Transport link resiliency is SCTP's strongest point (where it totally 428 outclasses all other TML proposals). Failure detection and recovery 429 is built in as mentioned earlier. 431 o With multi-homing, path diversity is provided. Should one of the 432 peer IP addresses become unreachable, the other(s) can be used 433 without involving lower layer (routing, for example) convergence 434 or even the TML becoming aware. 436 o With heartbeats and data transmission thresholds, on a per peer IP 437 address, reachability faults can be detected. The faults could be 438 a result of an unreachable address or peer, which may be caused by 439 a variety of reasons, like interface, network, or endpoint 440 failures. 442 o With the ADDIP feature, one can migrate IP addresses to other 443 nodes at runtime. This is not unlike the VRRP protocol use. 445 4.3.6. DOS prevention 447 Two separate streams are used within any FE-CE setup: the higher 448 priority one is for configuration and the lower priority one for data 449 redirection. The design is strict priority to further guarantee that 450 lower priority is starved if lack of resources happen. 452 4.3.7. Encapsulation 454 There is no extra encapsulation added by this TML. In the future, 455 should the need arise, SCTP provides for extensions to be added to it 456 by defining new chunks. 458 5. IANA Considerations 460 This document makes no request of IANA. 462 Note to RFC Editor: this section may be removed on publication as an 463 RFC. 465 6. Security Considerations 467 TBA: how to use TLS,IPSEC 469 7. Acknowledgements 471 8. References 473 8.1. Normative References 475 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 476 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 477 October 1998. 479 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 480 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 481 Zhang, L., and V. Paxson, "Stream Control Transmission 482 Protocol", RFC 2960, October 2000. 484 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 485 of IP Control and Forwarding", RFC 3654, November 2003. 487 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 488 "Forwarding and Control Element Separation (ForCES) 489 Framework", RFC 3746, April 2004. 491 8.2. Informative References 493 [FE-MODEL] 494 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 495 and S. Blake, "ForCES Forwarding Element Model", 496 Mar. 2006. 498 [FE-PROTO] 499 Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., 500 Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. 501 Gopal, "ForCES Protocol Specification", Mar. 2006. 503 [TML-API] M. Wang, W. and J. Hadi Salim, "ForCES Transport Mapping 504 Layer (TML) Service Primitives", Apr. 2006. 506 Author's Address 508 Jamal Hadi Salim 509 ZNYX Networks 510 Ottawa, Ontario 511 Canada 513 Email: hadi@znyx.com 515 Intellectual Property Statement 517 The IETF takes no position regarding the validity or scope of any 518 Intellectual Property Rights or other rights that might be claimed to 519 pertain to the implementation or use of the technology described in 520 this document or the extent to which any license under such rights 521 might or might not be available; nor does it represent that it has 522 made any independent effort to identify any such rights. Information 523 on the procedures with respect to rights in RFC documents can be 524 found in BCP 78 and BCP 79. 526 Copies of IPR disclosures made to the IETF Secretariat and any 527 assurances of licenses to be made available, or the result of an 528 attempt made to obtain a general license or permission for the use of 529 such proprietary rights by implementers or users of this 530 specification can be obtained from the IETF on-line IPR repository at 531 http://www.ietf.org/ipr. 533 The IETF invites any interested party to bring to its attention any 534 copyrights, patents or patent applications, or other proprietary 535 rights that may cover technology that may be required to implement 536 this standard. Please address the information to the IETF at 537 ietf-ipr@ietf.org. 539 Disclaimer of Validity 541 This document and the information contained herein are provided on an 542 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 543 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 544 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 545 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 546 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Copyright Statement 551 Copyright (C) The Internet Society (2006). This document is subject 552 to the rights, licenses and restrictions contained in BCP 78, and 553 except as set forth therein, the authors retain all their rights. 555 Acknowledgment 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.