idnits 2.17.1 draft-ietf-forces-sctptml-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 970: '... implement D/TLS MUST perform mutual a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (January 29, 2009) is 5558 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 627, but not defined ** Obsolete undefined reference: RFC 3768 (Obsoleted by RFC 5798) == Unused Reference: 'RFC2434' is defined on line 1026, 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 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Mojatatu Networks 4 Expires: August 2, 2009 K. Ogawa 5 NTT Corporation 6 January 29, 2009 8 SCTP based TML (Transport Mapping Layer) for ForCES protocol 9 draft-ietf-forces-sctptml-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 August 2, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document defines the SCTP based TML (Transport Mapping Layer) 49 for the ForCES protocol. It explains the rationale for choosing the 50 SCTP (Stream Control Transmission Protocol) [RFC2960] and also 51 describes how this TML addresses all the requirements described in 52 [RFC3654] and the ForCES protocol [FE-PROTO] draft. 54 Table of Contents 56 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 59 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5 62 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6 63 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8 65 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 9 66 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 10 67 4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14 68 5. Channel work scheduling . . . . . . . . . . . . . . . . . . . 15 69 5.1. FE Channel work scheduling . . . . . . . . . . . . . . . . 16 70 5.2. CE Channel work scheduling . . . . . . . . . . . . . . . . 17 71 6. Service Interface . . . . . . . . . . . . . . . . . . . . . . 17 72 6.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 18 73 6.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 19 74 6.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 20 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 77 8.1. TML Security Services using TLS and DTLS . . . . . . . . . 22 78 8.1.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . 22 79 8.2. TML Security Services using IPsec . . . . . . . . . . . . 23 80 8.2.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . 23 81 9. Manageability Considerations . . . . . . . . . . . . . . . . . 23 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 25 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 88 1. Definitions 90 The following definitions are taken from [RFC3654]and [RFC3746]: 92 ForCES Protocol -- The protocol used at the Fp reference point in the 93 ForCES Framework in [RFC3746]. 95 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 96 architecture that defines the ForCES protocol architecture and the 97 state transfer mechanisms as defined in [FE-PROTO]. 99 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 100 ForCES protocol architecture that specifically addresses the protocol 101 message transportation issues, such as how the protocol messages are 102 mapped to different transport media (like SCTP, IP, ATM, Ethernet, 103 etc), and how to achieve and implement reliability, security, etc. 105 2. Introduction 107 The ForCES (Forwarding and Control Element Separation) working group 108 in the IETF defines the architecture and protocol for separation of 109 Control Elements(CE) and Forwarding Elements(FE) in Network 110 Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively 111 define architectural and protocol requirements for the communication 112 between CE and FE. The ForCES protocol layer specification 113 [FE-PROTO] describes the protocol semantics and workings. The ForCES 114 protocol layer operates on top of an inter-connect hiding layer known 115 as the TML. The relationship is illustrated in Figure 1. 117 This document defines the SCTP based TML for the ForCES protocol 118 layer. It also addresses all the requirements for the TML including 119 security, reliability, etc as defined in [FE-PROTO]. 121 3. Protocol Framework Overview 123 The reader is referred to the Framework document [RFC3746], and in 124 particular sections 3 and 4, for an architectural overview and 125 explanation of where and how the ForCES protocol fits in. 127 There is some content overlap between the ForCES protocol draft 128 [FE-PROTO] and this section (Section 3) in order to provide basic 129 context to the reader of this document. 131 The ForCES protocol layering constitutes two pieces: the PL and TML 132 layer. This is depicted in Figure 1. 134 +----------------------------------------------+ 135 | CE PL | 136 +----------------------------------------------+ 137 | CE TML | 138 +----------------------------------------------+ 139 ^ 140 | 141 ForCES PL | messages 142 | 143 v 144 +-----------------------------------------------+ 145 | FE TML | 146 +-----------------------------------------------+ 147 | FE PL | 148 +-----------------------------------------------+ 150 Figure 1: Message exchange between CE and FE to establish an NE 151 association 153 The PL is in charge of the ForCES protocol. Its semantics and 154 message layout are defined in [FE-PROTO]. The TML is necessary to 155 connect two ForCES end-points as shown in Figure 1. 157 Both the PL and TML are standardized by the IETF. While only one PL 158 is defined, different TMLs are expected to be standardized. The TML 159 at each of the nodes (CE and FE) is expected to be of the same 160 definition in order to inter-operate. 162 When transmitting from a ForCES end-point, the PL delivers its 163 messages to the TML. The TML then delivers the PL message to the 164 destination TML(s). 166 On reception of a message, the TML delivers the message to its 167 destination PL level (as described in the ForCES header). 169 3.1. The PL 171 The PL is common to all implementations of ForCES and is standardized 172 by the IETF [FE-PROTO]. The PL level is responsible for associating 173 an FE or CE to an NE. It is also responsible for tearing down such 174 associations. 176 An FE may use the PL level to asynchronously send packets to the CE. 177 The FE may redirect via the PL (from outside the NE) various control 178 protocol packets (e.g. OSPF, etc) to the CE. Additionally, the FE 179 delivers various events that CE has subscribed-to via PL [FE-MODEL]. 181 The CE and FE may interact synchronously via the PL. The CE issues 182 status requests to the FE and receives responses via the PL. The CE 183 also configures the associated FE's LFBs' components using the PL 184 [FE-MODEL]. 186 3.2. The TML 188 The TML level is responsible for transport of the PL level messages. 189 [FE-PROTO] section 5 defines the requirements that need to be met by 190 a TML specification. The SCTP TML specified in this document meets 191 all the requirements specified in [FE-PROTO] section 5. 192 Section 4.2.2 describes how the TML requirements are met. 194 3.2.1. TML and PL Interfaces 196 There are two interfaces to the PL and TML, both of which are out of 197 scope for ForCES. The first one is the interface between the PL and 198 TML and the other is the CE Manager (CEM)/FE Manager (FEM)[RFC3746] 199 interface to both the PL and TML. Both interfaces are shown in 200 Figure 2. 202 [TML-API] defines an interface between the PL and the TML layers. 203 The end goal of [TML-API] is to provide a consistent top edge 204 semantics for all TMLs to adhere to. Conforming to such an interface 205 makes it easy to plug in different TMLs over time for a singular PL. 207 +----------------------------+ 208 | +----------------------+ | 209 | | | | 210 +---------+ | | PL Layer | | 211 | | | +----------------------+ | 212 |FEM/CEM |<---->| ^ | 213 | | | | | 214 +---------+ | |TML API | 215 | | | 216 | V | 217 | +----------------------+ | 218 | | | | 219 | | TML Layer | | 220 | | | | 221 | +----------------------+ | 222 +----------------------------+ 224 Figure 2: The TML-PL interface 226 XXX - Editorial Note: There is some concern (and confusion) about 227 defining APIs in ForCES. So at the moment the future of [TML-API] is 228 unknown and we will remove references to it in future revisions of 229 this document. 231 Figure 2 also shows an interface referred to as CEM/FEM[RFC3746] 232 which is responsible for bootstrapping and parameterization of the 233 TML. In its most basic form the CEM/FEM interface takes the form of 234 a simple static config file which is read on startup in the pre- 235 association phase. 237 Section 6 discusses in more details the service interfaces. 239 3.2.2. TML Parameterization 241 It is expected that it should be possible to use a configuration 242 reference point, such as the FEM or the CEM, to configure the TML. 244 Some of the configured parameters may include: 246 o PL ID 248 o Connection Type and associated data. For example if a TML uses 249 IP/SCTP then parameters such as SCTP ports and IP addresses need 250 to be configured. 252 o Number of transport connections 254 o Connection Capability, such as bandwidth, etc. 256 o Allowed/Supported Connection QoS policy (or Congestion Control 257 Policy) 259 4. SCTP TML overview 261 SCTP [RFC2960] is an end-to-end transport protocol that is equivalent 262 to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP 263 can do most of what UDP, TCP, or DCCP can achieve. SCTP as well can 264 do most of what a combination of the other transport protocols can 265 achieve (eg TCP and DCCP or TCP and UDP). 267 Like TCP, it provides ordered, reliable, connection-oriented, flow- 268 controlled, congestion controlled data exchange. Unlike TCP, it does 269 not provide byte streaming and instead provides message boundaries. 271 Like UDP, it can provide unreliable, unordered data exchange. Unlike 272 UDP, it does not provide multicast support 273 Like DCCP, it can provide unreliable, ordered, congestion controlled, 274 connection-oriented data exchange. 276 SCTP also provides other services that none of the 3 transport 277 protocols mentioned above provide. These include: 279 o Multi-homing 280 An SCTP connection can make use of multiple destination IP 281 addresses to communicate with its peer. 283 o Runtime IP address binding 284 With the SCTP Dynamic Address Reconfiguration ([RFC5061]) feature, 285 a new IP address can be bound at runtime. This allows for 286 migration of endpoints without restarting the association 287 (valuable for high availability). 289 o A range of reliability shades with congestion control 290 SCTP offers a range of services from full reliability to none, and 291 from full ordering to none. With SCTP, on a per message basis, 292 the application can specify a message's time-to-live. When the 293 expressed time expires, the message can be "skipped". 295 o Built-in heartbeats 296 SCTP has built-in heartbeat mechanism that validate the 297 reachability of peer addresses. 299 o Multi-streaming 300 A known problem with TCP is head of line (HOL) blocking. If you 301 have independent messages, TCP enforces ordering of such messages. 302 Loss at the head of the messages implies delays of delivery of 303 subsequent packets. SCTP allows for defining up to 64K 304 independent streams over the same socket connection, which are 305 ordered independently. 307 o Message boundaries with reliability 308 SCTP allows for easier message parsing (just like UDP but with 309 reliability built in) because it establishes boundaries on a PL 310 message basis. On a TCP stream, one would have to use techniques 311 such peeking into the message to figure the boundaries. 313 o Improved SYN DOS protection 314 Unlike TCP, which does a 3 way connection setup handshake, SCTP 315 does a 4 way handshake. This improves against SYN-flood attacks 316 because listening sockets do not set up state until a connection 317 is validated. 319 o Simpler transport events 320 An application (such as the TML) can subscribe to be notified of 321 both local and remote transport events. Events that can be 322 subscribed-to include indication of association changes, 323 addressing changes, remote errors, expiry of timed messages, etc. 324 These events are off by default and require explicit subscription. 326 o Simplified replicasting 327 Although SCTP does not allow for multicasting it allows for a 328 single message from an application to be sent to multiple peers. 329 This reduces the messaging that typically crosses different memory 330 domains within a host (example in a kernel to user space domain of 331 an operating system). 333 4.1. Rationale for using SCTP for TML 335 SCTP has all the features required to provide a robust TML. As a 336 transport that is all-encompassing, it negates the need for having 337 multiple transport protocols in order to satisfy the TML requirements 338 ([FE-PROTO] section 5). As a result it allows for simpler coding and 339 therefore reduces a lot of the interoperability concerns. 341 SCTP is also very mature and widely used making it a good choice for 342 ubiquitous deployment. 344 4.2. Meeting TML requirements 346 PL 347 +----------------------+ 348 | | 349 +-----------+----------+ 350 | TML API 351 TML | 352 +-----------+----------+ 353 | | | 354 | +------+------+ | 355 | | TML core | | 356 | +-+----+----+-+ | 357 | | | | | 358 | SCTP socket API | 359 | | | | | 360 | | | | | 361 | +-+----+----+-+ | 362 | | SCTP | | 363 | +------+------+ | 364 | | | 365 | | | 366 | +------+------+ | 367 | | IP | | 368 | +-------------+ | 369 +----------------------+ 371 Figure 3: The TML-SCTP interface 373 Figure 3 details the interfacing between the PL and SCTP TML and the 374 internals of the SCTP TML. The core of the TML interacts on its 375 north-bound interface to the PL (utilizing the TML API). On the 376 south-bound interface, the TML core interfaces to the SCTP layer 377 utilizing the standard socket interface [XXX Editorial: add here a 378 reference to SCTP Sockets API doc]. There are three SCTP socket 379 connections opened between any two PL endpoints (whether FE or CE). 381 4.2.1. SCTP TML Channels 383 +--------------------+ 384 | | 385 | TML core | 386 | | 387 +-+-------+--------+-+ 388 | | | 389 | Med prio, | 390 | Semi-reliable | 391 | channel | 392 | | Low prio, 393 | | Unreliable 394 | | channel 395 | | | 396 ^ ^ ^ 397 | | | 398 Y Y Y 399 High prio,| | | 400 reliable | | | 401 channel | | | 402 Y Y Y 403 +-+--------+--------+-+ 404 | | 405 | SCTP | 406 | | 407 +---------------------+ 409 Figure 4: The TML-SCTP channels 411 Figure 4 details further the interfacing between the TML core and 412 SCTP layers. There are 3 channels used to separate and prioritize 413 the different types of ForCES traffic. Each channel constitutes a 414 socket interface. It should be noted that all SCTP channels are 415 congestion aware (and for that reason that detail is left out of the 416 description of the 3 channels). SCTP port 6700, 6701, 6702 are used 417 for the higher, medium and lower priority channels respectively. 419 4.2.1.1. Justifying Choice of 3 Sockets 421 SCTP allows up to 64K streams to be sent over a single socket 422 interface. The authors initially envisioned using a single socket 423 for all three channels (mapping a channel to an SCTP stream). This 424 simplifies programming of the TML as well as conserves use of SCTP 425 ports. 427 Further analysis revealed head of line blocking issues with this 428 initial approach. Lower priority packets not needing reliable 429 delivery could block higher priority packets (needing reliable 430 delivery) under congestion situation. For this reason, we elected to 431 go with mapping each of the three channels to a different SCTP socket 432 (instead of a different stream within a single socket). 434 4.2.1.2. Higher Priority, Reliable channel 436 The higher priority (HP) channel uses a standard SCTP reliable socket 437 on port 6700. It is used for CE solicited messages and their 438 responses: 440 1. ForCES configuration messages flowing from CE to FE and responses 441 from the FE to CE. 443 2. ForCES query messages flowing from CE to FE and responses from 444 the FE to the CE. 446 It is recommended that the following PL messages use the HP channel 447 for transport: 449 o Association Setup 451 o Association Setup Response 453 o Association Teardown 455 o Config 457 o Config Response 459 o Query 461 o Query Response 463 4.2.1.3. Medium Priority, Semi-Reliable channel 465 The medium priority (MP) channel uses SCTP-PR on port 6701. Time 466 limits on how long a message is valid are set on each outgoing 467 message. This channel is used for events from the FE to the CE that 468 are obsoleted over time. Events that are accumulative in nature and 469 are recoverable by the CE (by issuing a query to the FE) can tolerate 470 lost events and therefore should use this channel. For example, a 471 generated event which carries the value of a counter that is 472 monotonically incrementing fits to use this channel. 474 It is recommended that the following PL messages use the MP channel 475 for transport: 477 o Event Notification 479 4.2.1.4. Lower Priority, Unreliable channel 481 The lower priority (LP) channel uses SCTP port 6702. This channel 482 also uses SCTP-PR with lower timeout values than the MP channel. The 483 reason an unreliable channel is used for redirect messages is to 484 allow the control protocol at both the CE and its peer-endpoint to 485 take charge of how the end-to-end semantics of the said control 486 protocol's operations. For example: 488 1. Some control protocols are reliable in nature, therefore making 489 this channel reliable introduces an extra layer of reliability 490 which could be harmful. So any end-to-end retransmits will 491 happen from remote. 493 2. Some control protocols may desire to have obsolescence of 494 messages over retransmissions; making this channel reliable 495 contradicts that desire. 497 Given ForCES PL level heartbeats are traffic sensitive, sending them 498 over the LP channel also makes sense. If the other end is not 499 processing other channels it will eventually get heartbeats; and if 500 it is busy processing other channels heartbeats will be obsoleted 501 locally over time (and it does not matter if they did not make it). 503 It is recommended that the following PL messages use the MP channel 504 for transport: 506 o Packet Redirect 508 o Heartbeats 510 4.2.1.5. Scheduling of The 3 Channels 512 Strict priority work-conserving scheduling is used to process both on 513 sending and receiving (of the PL messages) by the TML Core as shown 514 in Figure 5. 516 This means that the HP messages are always processed first until 517 there are no more left. The LP channel is processed only if a 518 channel that is higher priority than itself has no more messages left 519 to process. This means that under congestion situation, a higher 520 priority channel with sufficient messages that occupy the available 521 bandwidth would starve lower priority channel(s). 523 The design intent of the SCTP TML is to tie prioritization as 524 described in Section 4.2.1.1 and transport congestion control to 525 provide implicit node congestion control. This is further detailed 526 in Section 5. 528 SCTP channel +----------+ 529 Work available | DONE +---<--<--+ 530 | +---+------+ | 531 Y ^ 532 | +-->--+ +-->---+ | 533 +-->-->-+ | | | | | 534 | | | | | | ^ 535 | ^ ^ Y ^ Y | 536 ^ / \ | | | | | 537 | / \ | ^ | ^ ^ 538 | / Is \ | / \ | / \ | 539 | / there \ | /Is \ | /Is \ | 540 ^ / HP work \ ^ /there\ ^ /there\ ^ 541 | \ ? / | /MP work\ | /LP work\ | 542 | \ / | \ ? / | \ ? / | 543 | \ / | \ / | \ / ^ 544 | \ / ^ \ / ^ \ / | 545 | \ / | \ / | \ / | 546 ^ Y-->-->-->+ Y-->-->-->+ Y->->->-+ 547 | | NO | NO | NO 548 | | | | 549 | Y Y Y 550 | | YES | YES | 551 ^ | | | 552 | Y Y Y 553 | +----+------+ +---|-------+ +----|------+ 554 | |- process | |- process | |- process | 555 | | HP work | | MP work | | LP work | 556 | +------+----+ +-----+-----+ +-----+-----+ 557 | | | | 558 ^ Y Y Y 559 | | | | 560 | Y Y Y 561 +--<--<---+--<--<----<----+-----<---<-----+ 563 Figure 5: SCTP TML Strict Priority Scheduling 565 4.2.1.6. SCTP TML Parameterization 567 The following is a list of parameters needed for booting the TML. It 568 is expected these parameters will be extracted via the FEM/CEM 569 interface for each PL ID. 571 1. The IP address or a resolvable DNS/hostname of the CE/FE. 573 2. The HP SCTP port, as discussed in Section 4.2.1.2. The default 574 HP port value is 6700 (Section 7). 576 3. The MP SCTP port, as discussed in Section 4.2.1.3. default MP 577 port value is 6701 (Section 7). 579 4. The LP SCTP port, as discussed in Section 4.2.1.4. default LP 580 port value is 6702 (Section 7). 582 4.2.2. Satisfying TML Requirements 584 [FE-PROTO] section 5 lists requirements that a TML needs to meet. 585 This section describes how the SCTP TML satisfies those requirements. 587 4.2.2.1. Satisfying Reliability Requirement 589 As mentioned earlier, a shade of reliability ranges is possible in 590 SCTP. Therefore this requirement is met. 592 4.2.2.2. Satisfying Congestion Control Requirement 594 Congestion control is built into SCTP. Therefore, this requirement 595 is met. 597 4.2.2.3. Satisfying Timeliness and Prioritization Requirement 599 By using 3 sockets in conjunction with the partial-reliability 600 feature, both timeliness and prioritization can be achieved. 602 4.2.2.4. Satisfying Addressing Requirement 604 There are no extra headers required for SCTP to fulfil this 605 requirement. SCTP can be told to replicast packets to multiple 606 destinations. The TML implementation will need to translate PL level 607 addresses, to a variety of unicast IP addresses in order to emulate 608 multicast and broadcast PL addresses. 610 4.2.2.5. Satisfying HA Requirement 612 Transport link resiliency is one of SCTP's strongest point. Failure 613 detection and recovery is built in, as mentioned earlier. 615 o The SCTP multi-homing feature is used to provide path diversity. 616 Should one of the peer IP addresses become unreachable, the 617 other(s) are used without needing lower layer convergence 618 (routing, for example) or even the TML becoming aware. 620 o SCTP heartbeats and data transmission thresholds are used on a per 621 peer IP address to detect reachability faults. The faults could 622 be a result of an unreachable address or peer, which may be caused 623 by a variety of reasons, like interface, network, or endpoint 624 failures. The cause of the fault is noted. 626 o With the ADDIP feature, one can migrate IP addresses to other 627 nodes at runtime. This is not unlike the VRRP[RFC3768] protocol 628 use. This feature is used in addition to multi-homing in a 629 planned migration of activity from one FE/CE to another. In such 630 a case, part of the provisioning recipe at the CE for replacing an 631 FE involves migrating activity of one FE to another. 633 4.2.2.6. Satisfying DOS Prevention Requirement 635 Three separate channels, one per socket, are used within any FE-CE 636 setup. The scheduling design for processing channels 637 (Section 4.2.1.5) is strict priority and ties transport and node 638 overload implicitly together. The HP channel work gets prioritized 639 at the expense of the MP and LP channels in the presence of low 640 processing and bandwidth resource conditions. I.e., if redirected 641 packets (from outside the NE) attempt to overload the NE, they get 642 assigned very low priority and obsoleted in short periods if either 643 the CE or FE is busy processing more important work or the CE-FE path 644 is congested. Refer to Section 5 for details. 646 4.2.2.7. Satisfying Encapsulation Requirement 648 There is no extra encapsulation added by the SCTP TML. 650 In the future, should the need arise, a new SCTP extension/chunk can 651 be defined to meet newer ForCES requirements [XXX: Editorial note: 652 provide reference to SCTP extensibility]. 654 5. Channel work scheduling 656 This section provides high level details of the scheduling view of 657 the SCTP TML core (Section 4.2.1). A practical scheduler 658 implementation takes care of many little details (such as timers, 659 work quanta, etc) not described in this document. The implementor is 660 left to take care of those details. 662 The CE(s) and FE(s) are coupled together in the principles of the 663 scheduling scheme described here to tie together node overload with 664 transport congestion. The design intent is to provide the highest 665 possible robust work throughput for the NE under any network or 666 processing congestion. 668 XXX (Editorial note): We need to solicit feedback whether it would 669 help implementors if we publish algorithm for the CE/FE scheduling in 670 the form of pseudo-code. 672 5.1. FE Channel work scheduling 674 The FE scheduling, in priority order, needs to I/O process: 676 1. The HP channel I/O in the following priority order: 678 1. Transmitting back to the CE any outstanding result of 679 executed work via the HP channel transmit path. 681 2. Taking new incoming work from the CE which creates ForCES 682 work to be executed by the FE. 684 2. ForCES events which result in transmission of unsolicited ForCES 685 packets to the CE via the MP channel. 687 3. Incoming Redirect work in the form of control packets that come 688 from the CE via LP channel. After redirect processing, these 689 packets get sent out on external (to the NE) interface. 691 4. Incoming Redirect work in the form of control packets that come 692 from other NEs via external (to the NE) interfaces. After some 693 processing, such packets are sent to the CE. 695 It is worth emphasizing at this point again that the SCTP TML 696 processes the channel work in strict priority. For example, as long 697 as there are messages to send to the CE on the HP channel, they will 698 be processed first until there are no more left before processing the 699 next priority work (which is to read new messages on the HP channel 700 incoming from the CE). 702 5.2. CE Channel work scheduling 704 The CE scheduling, in priority order, needs to deal with: 706 1. The HP channel I/O in the following priority order: 708 1. Process incoming responses to requests of work it made to the 709 FE(s). 711 2. Transmitting any outstanding HP work it needs for the FE(s) 712 to complete. 714 2. Incoming ForCES events from the FE(s) via the MP channel. 716 3. Outgoing Redirect work in the form of control packets that get 717 sent from the CE via LP channel destined to external (to the NE) 718 interface on FE(s). 720 4. Incoming Redirect work in the form of control packets that come 721 from other NEs via external (to the NE) interfaces on the FE(s). 723 It is worth to repeat for emphasis again that the SCTP TML processes 724 the channel work in strict priority. For example, if there are 725 messages incoming from an FE on the HP channel, they will be 726 processed first until there are no more left before processing the 727 next priority work which is to transmit any outstanding HP channel 728 messages going to the FE. 730 6. Service Interface 732 XXX - Editorial Note and repeated emphasis: There is some concern 733 (and confusion) about defining APIs in ForCES. So at the moment the 734 future of [TML-API] is unknown and we will remove references to it in 735 future revisions of this document. 737 This section provides high level service interface between FEM/CEM 738 and TML, the PL and TML, and between local and remote TMLs. The 739 intent of this interface discussion is to provide general guidelines. 740 The implementer is expected to worry about details and even follow a 741 different approach if needed. 743 The theory of operation for the PL-TML service is as follows: 745 1. The PL starts up and bootstraps the TML. The end result of a 746 successful TML bootstrap is that the CE TML and the FE TML 747 connect to each other at the transport level. 749 2. Sending and reception of the PL level messages commences after a 750 successful TML bootstrap. The PL uses send and receive PL-TML 751 interfaces to communicate to its peers. The TML is agnostic to 752 the nature of the messages being sent or received. The first 753 message exchanges that happen are to establish ForCES 754 association. Subsequent messages maybe either unsolicited events 755 from the FE PL, control message redirects from/to the CE to/from 756 FE, and configuration from the CE to the FE and their responses 757 flowing from the FE to the CE. 759 3. The PL does a shutdown of the TML after terminating ForCES 760 association. 762 6.1. TML Boot-strapping 764 Figure 6 illustrates a flow for the TML bootstrapped by the PL. 766 When the PL starts up (possibly after some internal initialization), 767 it boots up the TML. The TML first interacts with the FEM/CEM and 768 acquires the necessary TML parameterization (Section 4.2.1.6). Next 769 the TML uses the information it retrieved from the FEM/CEM interface 770 to initialize itself. 772 The TML on the FE proceeds to connect the 3 channels to the CE. The 773 socket interface is used for each of the channels. The TML continues 774 to re-try the connections to the CE until all 3 channels are 775 connected. It is advisable that the number of connection retry 776 attempts and the time between each retry is also configurable via the 777 FEM. On failure to connect one or more channels, and after the 778 configured number of retry thresholds is exceeded, the TML will 779 return an appropriate failure indicator to the PL. On success (as 780 shown in Figure 6), a success indication is presented to the TML. 782 FE PL FE TML FEM CEM CE TML CE PL 783 | | | | | | 784 | | | | | Bootup | 785 | | | | |<-------------------| 786 | Bootup | | | | | 787 |----------->| | |get CEM info| | 788 | |get FEM info | |<-----------| | 789 | |------------>| ~ ~ | 790 | ~ ~ |----------->| | 791 | |<------------| | | 792 | | |-initialize TML | 793 | | |-create the 3 chans.| 794 | | | to listen to FEs | 795 | | | | 796 | |-initialize TML |Bootup success | 797 | |-create the 3 chans. locally |------------------->| 798 | |-connect 3 chans. remotely | | 799 | |------------------------------>| | 800 | ~ ~ - FE TML connected ~ 801 | ~ ~ - FE TML info init ~ 802 | | channels connected | | 803 | |<------------------------------| | 804 | Bootup | | | 805 | succeeded | | | 806 |<-----------| | | 807 | | | | 809 Figure 6: SCTP TML Bootstrapping 811 On the CE things are slightly different. After initializing from the 812 CEM, the TML on the CE side proceeds to initialize the 3 channels to 813 listen to remote connections from the FEs. The success or failure 814 indication is passed on to the CE PL level (in the same manner as was 815 done in the FE). 817 Post boot-up, the CE TML waits for connections from the FEs. Upon a 818 successful connection by an FE, the CE TML level keeps track of the 819 transport level details of the FE. Note, at this stage only 820 transport level connection has been established; ForCES level 821 association follows using send/receive PL-TML interfaces (refer to 822 Section 6.3 and Figure 8). 824 6.2. TML Shutdown 826 Figure 7 shows an example of an FE shutting down the TML. It is 827 assumed at this point that the ForCES Association Teardown has been 828 issued by the CE. 830 When the FE PL issues a shutdown to its TML for a specific PL ID, the 831 TML releases all the channel connections to the CE. This is achieved 832 by closing the sockets used to communicate to the CE. 834 FE PL FE TML CE TML CE PL 835 | | | | 836 | Shutdown | | | 837 |----------->| | | 838 | |-disconnect 3 chans. | | 839 | |------------------------>| | 840 | | | | 841 | | |-FE TML info cleanup| 842 | | |-optionally tell PL | 843 | | |------------------->| 844 | |- clean up any state of | | 845 | | channels disconnected | | 846 | | | | 847 | |<------------------------| | 848 | Shutdown | | | 849 | succeeded | | | 850 |<-----------| | | 851 | | | | 853 Figure 7: FE Shutting down 855 On the CE side, a TML level disconnection would result in possible 856 cleanup of the FE state. Optionally, depending on the 857 implementation, there may be need to inform the PL about the TML 858 disconnection. 860 6.3. TML Sending and Receiving 862 The TML is agnostic to the nature of the PL message it delivers to 863 the remote TML (which subsequently delivers the message to its PL). 864 Figure 8 shows an example of a message exchange originated at the FE 865 and sent to the CE (such as a ForCES association message) which 866 illustrates all the necessary service interfaces for sending and 867 receiving. 869 When the FE PL sends a message to the TML, the TML is expected to 870 pick one of HP/MP/LP channels and send out the ForCES message. 872 FE PL FE TML CE TML CE PL 873 | | | | 874 |PL send | | | 875 |----------->| | | 876 | | | | 877 | |-Format msg. | | 878 | |-pick channel | | 879 | |-TML Send | | 880 | |------------->| | 881 | | |-TML Receive on chan. | 882 | | |-decapsulate | 883 | | |- mux to PL/PL recv | 884 | | |--------------------->| 885 | | | ~ 886 | | | ~ PL Process 887 | | | ~ 888 | | | PL send | 889 | | |<---------------------| 890 | | |-Format msg. for send | 891 | | |-pick chan to send on | 892 | | |-TML send | 893 | |<-------------| | 894 | |-TML Receive | | 895 | |-decapsulate | | 896 | |-mux to PL | | 897 | PL Recv | | | 898 |<---------- | | | 899 | | | | 901 Figure 8: Send and Recv Flow 903 When the CE TML receives the ForCES message on the channel it was 904 sent on, it demultiplexes the message to the CE PL. 906 The CE PL, after some processing (in this example dealing with the 907 FE's association), sends to the TML the response. And as in the case 908 of FE PL, the CE TML picks the channel to send on before sending. 910 The processing of the ForCES message upon arriving at the FE TML and 911 delivery to the FE PL is similar to the CE side equivalent as shown 912 above in Section 6.3. 914 7. IANA Considerations 916 This document makes request of IANA to reserve SCTP ports 6700, 6701, 917 and 6702. 919 8. Security Considerations 921 The SCTP TML provides the following security services to the PL 922 level: 924 o A mechanism to authenticate ForCES CEs and FEs at transport level 925 in order to prevent the participation of unauthorized CEs and 926 unauthorized FEs in the control and data path processing of a 927 ForCES NE. 929 o A mechanism to ensure message authentication of PL data and 930 headers transferred from the CE to FE (and vice-versa) in order to 931 prevent the injection of incorrect data into PL messages. 933 o A mechanism to ensure the confidentiality of PL data and headers 934 transferred from the CE to FE (and vice-versa), in order to 935 prevent disclosure of PL level information transported via the 936 TML. 938 Security choices provided by the TML are made by the operator and 939 take effect during the pre-association phase of the ForCES protocol. 940 An operator may choose to use all, some or none of the security 941 services provided by the TML in a CE-FE connection. 943 When operating under a secured environment, or for other operational 944 concerns (in some cases performance issues) the operator may turn off 945 all the security functions between CE and FE. 947 The operator has the choice of configuring either a combination of 948 Transport Layer Security(TLS) [RFC4346] and Datagram Transport Layer 949 Security(DTLS) [RFC4347], or IP Security Protocol (IPsec) [RFC4301] 950 to provide needed security. It is recommended that the TLS/DTLS 951 combination is used and only in its absence should IPsec be 952 considered. 954 XXXX: Editors note: we should take note of RFC 3554 and 3436 956 8.1. TML Security Services using TLS and DTLS 958 TLS and DTLS were designed to provide the mutual authentication, 959 message integrity and message confidentiality outlined in the TML 960 security requirements ([FE-PROTO]). 962 8.1.1. TLS Usage 964 Since in the ForCES architecture, the CE is master and FEs are 965 slaves, the FEs are D/TLS clients and CEs are D/TLS server. The FE 966 HP channel opens a TLS connection on SCTP port 6700. The FE MP and 967 LP channels open DTLS connections on SCTP ports 6701 and 6702 968 respectively. 970 The endpoints that implement D/TLS MUST perform mutual authentication 971 during D/TLS session establishment process. Certificates are used to 972 achieve mutual authentication. 974 We recommend TLS-RSA-with-AES-128-CBC-SHA cipher suite. Although 975 consistency is expected it is possible for the CE or FE to negotiate 976 other D/TLS cipher suites. 978 8.2. TML Security Services using IPsec 980 XXXX: Editors note: We should review what RFCs to list as references 981 (eg IKEv2, ESP etc). 983 IPsec is an IP level security scheme transparent to the higher-layer 984 applications and therefore can provide security for any transport 985 layer protocol. This gives IPsec the advantage that it can be used 986 to secure everything between the CE and FE without expecting the TML 987 implementation to be aware of the details. 989 The IPsec architecture is designed to provide message integrity and 990 message confidentiality outlined in the TML security requirements 991 ([FE-PROTO]). Mutual authentication and key exchange protocol 992 Internet Key Exchange (IKE)[RFC4109]. 994 8.2.1. IPsec Usage 996 It is recommended that the following options be used for consistency 997 (although it is expected to be possible for the CE or FE to negotiate 998 other cipher suites): 1000 o Internet Key Exchange (IKE)[RFC4109] with certificates for 1001 endpoint authentication. 1003 o Transport Mode Encapsulating Security Payload (ESP) 1005 o HMAC-SHA1-96 [RFC2404] for message integrity protection 1007 o AES-CBC with 128-bit keys [RFC3602] for message confidentiality. 1009 9. Manageability Considerations 1011 TBA 1013 10. Acknowledgements 1015 The authors would like to thank Joel Halpern, Michael Tuxen and Randy 1016 Stewart for engaging us in discussions that have made this draft 1017 better. 1019 11. References 1021 11.1. Normative References 1023 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1024 ESP and AH", RFC 2404, November 1998. 1026 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1027 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1028 October 1998. 1030 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1031 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1032 Zhang, L., and V. Paxson, "Stream Control Transmission 1033 Protocol", RFC 2960, October 2000. 1035 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1036 Algorithm and Its Use with IPsec", RFC 3602, 1037 September 2003. 1039 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 1040 of IP Control and Forwarding", RFC 3654, November 2003. 1042 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 1043 "Forwarding and Control Element Separation (ForCES) 1044 Framework", RFC 3746, April 2004. 1046 [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1047 1 (IKEv1)", RFC 4109, May 2005. 1049 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1050 Internet Protocol", RFC 4301, December 2005. 1052 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1053 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1055 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1056 Security", RFC 4347, April 2006. 1058 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 1059 Kozuka, "Stream Control Transmission Protocol (SCTP) 1060 Dynamic Address Reconfiguration", RFC 5061, 1061 September 2007. 1063 11.2. Informative References 1065 [FE-MODEL] 1066 Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element 1067 Model", October 2008. 1069 [FE-PROTO] 1070 Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., 1071 Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. 1072 Gopal, "ForCES Protocol Specification", November 2008. 1074 [TML-API] M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES 1075 Transport Mapping Layer (TML) Service Primitives", 1076 Feb. 2007. 1078 Authors' Addresses 1080 Jamal Hadi Salim 1081 Mojatatu Networks 1082 Ottawa, Ontario 1083 Canada 1085 Email: hadi@mojatatu.com 1087 Kentaro Ogawa 1088 NTT Corporation 1089 3-9-11 Midori-cho 1090 Musashino-shi, Tokyo 180-8585 1091 Japan 1093 Email: ogawa.kentaro@lab.ntt.co.jp