idnits 2.17.1 draft-ietf-forces-sctptml-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 19, 2010) is 5204 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) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-sctpsocket-20 -- Obsolete informational reference (is this intentional?): RFC 3768 (Obsoleted by RFC 5798) Summary: 4 errors (**), 0 flaws (~~), 2 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 Intended status: Standards Track K. Ogawa 5 Expires: July 23, 2010 NTT Corporation 6 January 19, 2010 8 SCTP based TML (Transport Mapping Layer) for ForCES protocol 9 draft-ietf-forces-sctptml-08 11 Abstract 13 This document defines the SCTP based TML (Transport Mapping Layer) 14 for the ForCES protocol. It explains the rationale for choosing the 15 SCTP (Stream Control Transmission Protocol) and also describes how 16 this TML addresses all the requirements required by and the ForCES 17 protocol. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 23, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 4 74 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 6 77 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 7 78 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 8 79 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8 80 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 9 81 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 10 82 4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 15 83 5. SCTP TML Channel Work . . . . . . . . . . . . . . . . . . . . 17 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 86 7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 19 87 7.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 19 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 91 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Appendix A. Suggested SCTP TML Channel Work Implementation . . . 21 93 A.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 21 94 A.2. Channel work scheduling . . . . . . . . . . . . . . . . . 22 95 A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 22 96 A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 22 97 A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 23 98 A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 24 99 Appendix B. Suggested Service Interface . . . . . . . . . . . . . 24 100 B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 25 101 B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 26 102 B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Definitions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119. 111 The following definitions are taken from [RFC3654]and [RFC3746]: 113 Logical Functional Block (LFB) -- A template that represents a fine- 114 grained, logically separate aspects of FE processing. 116 ForCES Protocol -- The protocol used at the Fp reference point in the 117 ForCES Framework in [RFC3746]. 119 ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES 120 architecture that embodies the ForCES protocol and the state transfer 121 mechanisms as defined in [I-D.ietf-forces-protocol]. 123 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 124 ForCES protocol architecture that specifically addresses the protocol 125 message transportation issues, such as how the protocol messages are 126 mapped to different transport media (like SCTP, IP, TCP, UDP, ATM, 127 Ethernet, etc), and how to achieve and implement reliability, 128 security, etc. 130 2. Introduction 132 The ForCES (Forwarding and Control Element Separation) working group 133 in the IETF defines the architecture and protocol for separation of 134 Control Elements(CE) and Forwarding Elements(FE) in Network 135 Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively 136 define architectural and protocol requirements for the communication 137 between CE and FE. The ForCES protocol layer specification 138 [I-D.ietf-forces-protocol] describes the protocol semantics and 139 workings. The ForCES protocol layer operates on top of an inter- 140 connect hiding layer known as the TML. The relationship is 141 illustrated in Figure 1. 143 This document defines the SCTP based TML for the ForCES protocol 144 layer. It also addresses all the requirements for the TML including 145 security, reliability, etc as defined in [I-D.ietf-forces-protocol]. 147 3. Protocol Framework Overview 149 The reader is referred to the Framework document [RFC3746], and in 150 particular sections 3 and 4, for an architectural overview and 151 explanation of where and how the ForCES protocol fits in. 153 There is some content overlap between the ForCES protocol 154 specification [I-D.ietf-forces-protocol] and this section (Section 3) 155 in order to provide basic context to the reader of this document. 157 The ForCES protocol layering constitutes two pieces: the PL and TML. 158 This is depicted in Figure 1. 160 +----------------------------------------------+ 161 | CE PL | 162 +----------------------------------------------+ 163 | CE TML | 164 +----------------------------------------------+ 165 ^ 166 | 167 ForCES PL |messages 168 | 169 v 170 +-----------------------------------------------+ 171 | FE TML | 172 +-----------------------------------------------+ 173 | FE PL | 174 +-----------------------------------------------+ 176 Figure 1: Message exchange between CE and FE to establish an NE 177 association 179 The PL is in charge of the ForCES protocol. Its semantics and 180 message layout are defined in [I-D.ietf-forces-protocol]. The TML is 181 necessary to connect two ForCES end-points as shown in Figure 1. 183 Both the PL and TML are standardized by the IETF. While only one PL 184 is defined, different TMLs are expected to be standardized. The TML 185 at each of the nodes (CE and FE) is expected to be of the same 186 definition in order to inter-operate. 188 When transmitting from a ForCES end-point, the PL delivers its 189 messages to the TML. The TML then delivers the PL message to the 190 destination TML(s). 192 On reception of a message, the TML delivers the message to its 193 destination PL (as described in the ForCES header). 195 3.1. The PL 197 The PL is common to all implementations of ForCES and is standardized 198 by the IETF [I-D.ietf-forces-protocol]. The PL is responsible for 199 associating an FE or CE to an NE. It is also responsible for tearing 200 down such associations. 202 An FE may use the PL to asynchronously send packets to the CE. The 203 FE may redirect via the PL (from outside the NE) various control 204 protocol packets (e.g. OSPF, etc) to the CE. Additionally, the FE 205 delivers various events that CE has subscribed-to via PL 206 [I-D.ietf-forces-model]. 208 The CE and FE may interact synchronously via the PL. The CE issues 209 status requests to the FE and receives responses via the PL. The CE 210 also configures the associated FE's LFBs' components using the PL 211 [I-D.ietf-forces-model]. 213 3.2. The TML 215 The TML is responsible for transport of the PL messages. 216 [I-D.ietf-forces-protocol] section 5 defines the requirements that 217 need to be met by a TML specification. The SCTP TML specified in 218 this document meets all the requirements specified in 219 [I-D.ietf-forces-protocol] section 5. Section 4.2.2 describes how 220 the TML requirements are met. 222 3.2.1. TML and PL Interfaces 224 There are two interfaces to the PL and TML. The specification of 225 these interfaces is out of scope for this document, but the 226 interfaces are introduced to show how they fit into the architecture 227 and summarize the function provided at the interfaces. The first 228 interface is between the PL and TML and the other is the CE Manager 229 (CEM)/FE Manager (FEM)[RFC3746] interface to both the PL and TML. 230 Both interfaces are shown in Figure 2. 232 +----------------------------+ 233 | +----------------------+ | 234 | | | | 235 +---------+ | | PL | | 236 | | | +----------------------+ | 237 |FEM/CEM |<---->| ^ | 238 | | | | | 239 +---------+ | |TML API | 240 | | | 241 | V | 242 | +----------------------+ | 243 | | | | 244 | | TML | | 245 | | | | 246 | +----------------------+ | 247 +----------------------------+ 249 Figure 2: The TML-PL interface 251 The CEM/FEM[RFC3746] interface is responsible for bootstrapping and 252 parameterization of the TML. In its most basic form the CEM/FEM 253 interface takes the form of a simple static config file which is read 254 on startup in the pre-association phase. 256 Appendix B discusses in more details the service interfaces. 258 3.2.2. TML Parameterization 260 It is expected that it should be possible to use a configuration 261 reference point, such as the FEM or the CEM, to configure the TML. 263 Some of the configured parameters may include: 265 o PL ID 267 o Connection Type and associated data. For example if a TML uses 268 IP/SCTP then parameters such as SCTP ports and IP addresses need 269 to be configured. 271 o Number of transport connections 273 o Connection Capability, such as bandwidth, etc. 275 o Allowed/Supported Connection QoS policy (or Congestion Control 276 Policy) 278 4. SCTP TML overview 280 SCTP [RFC4960] is an end-to-end transport protocol that is equivalent 281 to TCP, UDP, or DCCP in many aspects. With a few exceptions, SCTP 282 can do most of what UDP, TCP, or DCCP can achieve. SCTP as well can 283 do most of what a combination of the other transport protocols can 284 achieve (e.g. TCP and DCCP or TCP and UDP). 286 Like TCP, it provides ordered, reliable, connection-oriented, flow- 287 controlled, congestion controlled data exchange. Unlike TCP, it does 288 not provide byte streaming and instead provides message boundaries. 290 Like UDP, it can provide unreliable, unordered data exchange. Unlike 291 UDP, it does not provide multicast support 293 Like DCCP, it can provide unreliable, ordered, congestion controlled, 294 connection-oriented data exchange. 296 SCTP also provides other services that none of the 3 transport 297 protocols mentioned above provide that we found attractive. These 298 include: 300 o Multi-homing 302 o Runtime IP address binding 304 o A range of reliability shades with congestion control 306 o Built-in heartbeats 308 o Multi-streaming 310 o Message boundaries with reliability 312 o Improved SYN DOS protection 314 o Simpler transport events 316 o Simplified replicasting 318 4.1. Rationale for using SCTP for TML 320 SCTP has all the features required to provide a robust TML. As a 321 transport that is all-encompassing, it negates the need for having 322 multiple transport protocols in order to satisfy the TML requirements 323 ([I-D.ietf-forces-protocol] section 5). As a result it allows for 324 simpler coding and therefore reduces a lot of the interoperability 325 concerns. 327 SCTP is also very mature and widely used, making it a good choice for 328 ubiquitous deployment. 330 4.2. Meeting TML requirements 332 PL 333 +----------------------+ 334 | | 335 +-----------+----------+ 336 | TML API 337 TML | 338 +-----------+----------+ 339 | | | 340 | +------+------+ | 341 | | TML core | | 342 | +-+----+----+-+ | 343 | | | | | 344 | SCTP socket API | 345 | | | | | 346 | | | | | 347 | +-+----+----+-+ | 348 | | SCTP | | 349 | +------+------+ | 350 | | | 351 | | | 352 | +------+------+ | 353 | | IP | | 354 | +-------------+ | 355 +----------------------+ 357 Figure 3: The TML-SCTP interface 359 Figure 3 details the interfacing between the PL and SCTP TML and the 360 internals of the SCTP TML. The core of the TML interacts on its 361 north-bound interface to the PL (utilizing the TML API). On the 362 south-bound interface, the TML core interfaces to the SCTP layer 363 utilizing the standard socket interface[I-D.ietf-tsvwg-sctpsocket]. 364 There are three SCTP socket connections opened between any two PL 365 endpoints (whether FE or CE). 367 4.2.1. SCTP TML Channels 369 +--------------------+ 370 | | 371 | TML core | 372 | | 373 +-+-------+--------+-+ 374 | | | 375 | Med prio, | 376 | Semi-reliable | 377 | channel | 378 | | Low prio, 379 | | Unreliable 380 | | channel 381 | | | 382 ^ ^ ^ 383 | | | 384 Y Y Y 385 High prio,| | | 386 reliable | | | 387 channel | | | 388 Y Y Y 389 +-+--------+--------+-+ 390 | | 391 | SCTP | 392 | | 393 +---------------------+ 395 Figure 4: The TML-SCTP channels 397 Figure 4 details further the interfacing between the TML core and 398 SCTP layers. There are 3 channels used to group and prioritize the 399 work for different types of ForCES traffic. Each channel constitutes 400 an SCTP socket interface which has different properties. It should 401 be noted that all SCTP channels are congestion aware (and for that 402 reason that detail is left out of the description of the 3 channels). 403 SCTP port 6704, 6705, 6706 are used for the higher, medium and lower 404 priority channels respectively. SCTP Payload Protocol ID (PPID) 405 values of 21, 22, and 23 are used for the higher, medium and lower 406 priority channels respectively. 408 4.2.1.1. Justifying Choice of 3 Sockets 410 SCTP allows up to 64K streams to be sent over a single socket 411 interface. The authors initially envisioned using a single socket 412 for all three channels (mapping a channel to an SCTP stream). This 413 simplifies programming of the TML as well as conserves use of SCTP 414 ports. 416 Further analysis revealed head of line blocking issues with this 417 initial approach. Lower priority packets not needing reliable 418 delivery could block higher priority packets (needing reliable 419 delivery) under congestion situation for an indeterminate period of 420 time (depending on how many outstanding lower priority packets are 421 pending). For this reason, we elected to go with mapping each of the 422 three channels to a different SCTP socket (instead of a different 423 stream within a single socket). 425 4.2.1.2. Higher Priority, Reliable channel 427 The higher priority (HP) channel uses a standard SCTP reliable socket 428 on port 6704. SCTP PPID 21 is used for all messages on the HP 429 channel. The HP channel is used for CE solicited messages and their 430 responses: 432 1. ForCES configuration messages flowing from CE to FE and responses 433 from the FE to CE. 435 2. ForCES query messages flowing from CE to FE and responses from 436 the FE to the CE. 438 PL priorities 4-7 MUST be used for all PL messages using this 439 channel. The following PL messages MUST use the HP channel for 440 transport: 442 o Association Setup (default priority: 7) 444 o Association Setup Response (default priority: 7) 446 o Association Teardown (default priority: 7) 448 o Config (default priority: 4) 450 o Config Response (default priority: 4) 452 o Query (default priority: 4) 454 o Query Response (default priority: 4) 456 If PL priorities outside of the specified range (4-7) priority, PPID 457 or PL message types other than the above are received on the HP 458 channel, then the PL message MUST be dropped. 460 Although an implementation may choose different values from the 461 defined range (4-7), it is RECOMMENDED that default priorities be 462 used. A response to a ForCES message MUST contain the same priority 463 as the request. Example, a config sent by the CE with priority 5 464 MUST have a config-response from the FE with priority 5. 466 4.2.1.3. Medium Priority, Semi-Reliable channel 468 The medium priority (MP) channel uses SCTP-PR on port 6705. SCTP 469 PPID 22 MUST be used for all messages on the MP channel. Time limits 470 on how long a message is valid are set on each outgoing message. 471 This channel is used for events from the FE to the CE that are 472 obsoleted over time. Events that are accumulative in nature and are 473 recoverable by the CE (by issuing a query to the FE) can tolerate 474 lost events and therefore should use this channel. For example, a 475 generated event which carries the value of a counter that is 476 monotonically incrementing fits to use this channel. 478 PL priority 3 MUST be used for PL messages on this channel. The 479 following PL messages MUST use the MP channel for transport: 481 o Event Notification (default priority: 3) 483 If PL priority outside of the specified priority, PPID or PL message 484 type other than the above are received on the MP channel, then the PL 485 message MUST be dropped. 487 4.2.1.4. Lower Priority, Unreliable channel 489 The lower priority (LP) channel uses SCTP port 6706. SCTP PPID 23 is 490 used for all messages on the LP channel. The LP channel also MUST 491 use SCTP-PR with lower timeout values than the MP channel. The 492 reason an unreliable channel is used for redirect messages is to 493 allow the control protocol at both the CE and its peer-endpoint to 494 take charge of how the end-to-end semantics of the said control 495 protocol's operations. For example: 497 1. Some control protocols are reliable in nature, therefore making 498 this channel reliable introduces an extra layer of reliability 499 which could be harmful. So any end-to-end retransmits will 500 happen from remote. 502 2. Some control protocols may desire to have obsolescence of 503 messages over retransmissions; making this channel reliable 504 contradicts that desire. 506 Given ForCES PL heartbeats are traffic sensitive, sending them over 507 the LP channel also makes sense. If the other end is not processing 508 other channels it will eventually get heartbeats; and if it is busy 509 processing other channels heartbeats will be obsoleted locally over 510 time (and it does not matter if they did not make it). 512 PL priorities 1-2 MUST be used for PL messages on this channel. PL 513 messages that MUST use the MP channel for transport are: 515 o Packet Redirect (default priority: 2) 517 o Heartbeats (default priority: 1) 519 If PL priorities outside of the specified priority range, PPID or PL 520 message types other than the above are received on the LP channel, 521 then the PL message MUST be dropped. 523 4.2.1.5. Scheduling of The 3 Channels 525 Strict priority work-conserving scheduling is used to process both on 526 sending and receiving (of the PL messages) by the TML Core as shown 527 in Figure 5. 529 This means that the HP messages are always processed first until 530 there are no more left. The LP channel is processed only if channels 531 that are a higher priority than itself has no more messages left to 532 process. This means that under congestion situation, a higher 533 priority channel with sufficient messages that occupy the available 534 bandwidth would starve lower priority channel(s). 536 The design intent of the SCTP TML is to tie processing prioritization 537 as described in Section 4.2.1.1 and transport congestion control to 538 provide implicit node congestion control. This is further detailed 539 in Appendix A.2. 541 It should be emphasized that the work scheduling prioritization 542 scheme prescribed in this document is receiver based processing. 543 Fully arrived packets on any of the channels are a source of work 544 whose output may result in transmitted packets. However, we have no 545 control on the order in which SCTP/OS/network chooses to send 546 transmitted packets across and make them available to the receiver. 547 This is a limitation that we try to ameliorate by our choice of 548 channel properties, ForCES message grouping and the tying of CE and 549 FE work scheduling. And while that helps us ameliorate some of these 550 issues it does not fully resolve all. 552 From a ForCES perspective, we can tolerate some reordering. Example: 553 If an FE transmits a config response (HP), followed by 10000 OSPF 554 redirect packets(LP) and the CE gets 5 OSPF redirects (LP) first 555 before the config response(HP), that is tolerable. What matters is 556 the CE gets to processing the HP message soon (instead of sitting in 557 long periods of time processing OSPF packets which would have 558 happened if we use a single socket with 3 streams). This is 559 particularly important in order to deal well with node overload as 560 discussed in Section 4.2.2.6. 562 SCTP channel +----------+ 563 Work available | DONE +---<--<--+ 564 | +---+------+ | 565 Y ^ 566 | +-->--+ +-->---+ | 567 +-->-->-+ | | | | | 568 | | | | | | ^ 569 | ^ ^ Y ^ Y | 570 ^ / \ | | | | | 571 | / \ | ^ | ^ ^ 572 | / Is \ | / \ | / \ | 573 | / there \ | /Is \ | /Is \ | 574 ^ / HP work \ ^ /there\ ^ /there\ ^ 575 | \ ? / | /MP work\ | /LP work\ | 576 | \ / | \ ? / | \ ? / | 577 | \ / | \ / | \ / ^ 578 | \ / ^ \ / ^ \ / | 579 | \ / | \ / | \ / | 580 ^ Y-->-->-->+ Y-->-->-->+ Y->->->-+ 581 | | NO | NO | NO 582 | | | | 583 | Y Y Y 584 | | YES | YES | YES 585 ^ | | | 586 | Y Y Y 587 | +----+------+ +---|-------+ +----|------+ 588 | |- process | |- process | |- process | 589 | | HP work | | MP work | | LP work | 590 | +------+----+ +-----+-----+ +-----+-----+ 591 | | | | 592 ^ Y Y Y 593 | | | | 594 | Y Y Y 595 +--<--<---+--<--<----<----+-----<---<-----+ 597 Figure 5: SCTP TML Strict Priority Scheduling 599 4.2.1.6. SCTP TML Parameterization 601 The following is a list of parameters needed for booting the TML. It 602 is expected these parameters will be extracted via the FEM/CEM 603 interface for each PL ID. 605 1. The IP address(es) or a resolvable DNS/hostname(s) of the CE/FE. 607 2. Whether to use IPsec or not. If IPsec is used, how to 608 parameterize the different required ciphers, keys etc as 609 described in Section 7.1 611 3. The HP SCTP port, as discussed in Section 4.2.1.2. The default 612 HP port value is 6704 (Section 6). 614 4. The MP SCTP port, as discussed in Section 4.2.1.3. The default 615 MP port value is 6705 (Section 6). 617 5. The LP SCTP port, as discussed in Section 4.2.1.4. The default 618 LP port value is 6706 (Section 6). 620 4.2.2. Satisfying TML Requirements 622 [I-D.ietf-forces-protocol] section 5 lists requirements that a TML 623 needs to meet. This section describes how the SCTP TML satisfies 624 those requirements. 626 4.2.2.1. Satisfying Reliability Requirement 628 As mentioned earlier, a shade of reliability ranges is possible in 629 SCTP. Therefore this requirement is met. 631 4.2.2.2. Satisfying Congestion Control Requirement 633 Congestion control is built into SCTP. Therefore, this requirement 634 is met. 636 4.2.2.3. Satisfying Timeliness and Prioritization Requirement 638 By using 3 sockets in conjunction with the partial-reliability 639 feature[RFC3758], both timeliness and prioritization requirements are 640 addressed. 642 4.2.2.4. Satisfying Addressing Requirement 644 There are no extra headers required for SCTP to fulfil this 645 requirement. SCTP can be told to replicast packets to multiple 646 destinations. The TML implementation will need to translate PL 647 addresses, to a variety of unicast IP addresses in order to emulate 648 multicast and broadcast PL addresses. 650 4.2.2.5. Satisfying High Availability Requirement 652 Transport link resiliency is one of SCTP's strongest point. Failure 653 detection and recovery is built in, as mentioned earlier. 655 o The SCTP multi-homing feature is used to provide path diversity. 656 Should one of the peer IP addresses become unreachable, the 657 other(s) are used without needing lower layer convergence 658 (routing, for example) or even the TML becoming aware. 660 o SCTP heartbeats and data transmission thresholds are used on a per 661 peer IP address to detect reachability faults. The faults could 662 be a result of an unreachable address or peer, which may be caused 663 by a variety of reasons, like interface, network, or endpoint 664 failures. The cause of the fault is noted. 666 o With the ADDIP feature, one can migrate IP addresses to other 667 nodes at runtime. This is not unlike the VRRP[RFC3768] protocol 668 use. This feature is used in addition to multi-homing in a 669 planned migration of activity from one FE/CE to another. In such 670 a case, part of the provisioning recipe at the CE for replacing an 671 FE involves migrating activity of one FE to another. 673 4.2.2.6. Satisfying Node Overload Prevention Requirement 675 The architecture of this TML defines three separate channels, one per 676 socket, to be used within any FE-CE setup. The work scheduling 677 design for processing the TML channels (Section 4.2.1.5) is strict 678 priority. A fundamental desire of the strict prioritization is to 679 ensure that more important processing work always gets node resources 680 over lesser important work. 682 When a ForCES node CPU is overwhelmed because the incoming packet 683 rate is higher than it can keep up with, the channel queues grow and 684 transport congestion subsequently follows. By virtue of using SCTP, 685 the congestion is propagated back to the source of the incoming 686 packets and eventually alleviated. 688 The HP channel work gets prioritized at the expense of the MP which 689 gets prioritized over LP channels. The preferential scheduling only 690 kicks in when there is node overload regardless of whether there is 691 transport congestion. As a result of the preferential work 692 treatment, the ForCES node achieves a robust steady processing 693 capacity. Refer to Appendix A.2 for details on scheduling. 695 For an example of how the overload prevention works: consider a 696 scenario where an overwhelming amount redirected packets (from 697 outside the NE) coming into the NE may overload the FE while it has 698 outstanding config work from the CE. In such a case, the FE, while 699 it is busy processing config requests from the CE essentially ignores 700 processing the redirect packets on the LP channel. If enough 701 redirect packets accumulate, they are dropped either because the LP 702 channel threshold is exceeded or because they are obsoleted. If on 703 the other hand, the FE has successfully processed the higher priority 704 channels and their related work, then it can proceed and process the 705 LP channel. So as demonstrated in this case, the TML ties transport 706 congestion and node overload implicitly together. 708 4.2.2.7. Satisfying Encapsulation Requirement 710 The SCTP TML sets SCTP PPIDs to identify channels used as described 711 in Section 4.2.1.1. 713 5. SCTP TML Channel Work 715 There are two levels of TML channel work within an NE when a ForCES 716 node (CE or FE) is connected to multiple other ForCES nodes: 718 1. NE-level I/O work where a ForCES node (CE or FE) needs to choose 719 which of the peer nodes to process. 721 2. Node-level I/O work where a ForCES node, handles the three SCTP 722 TML channels separately for each single ForCES endpoint. 724 NE-level scheduling definition is left up to the implementation and 725 is considered out of scope for this document. Appendix A.4 discuss 726 briefly some constraints that an implementer needs to worry about. 728 This document provides suggestions on SCTP channel work 729 implementation in Appendix A. 731 The FE SHOULD do channel connections to the CE in the order of 732 incrementing priorities i.e. LP socket first, followed by MP and 733 ending with HP socket connection. The CE, however, MUST NOT assume 734 that there is ordering of socket connections from any FE. 736 6. IANA Considerations 738 Following the policies outlined in "Guidelines for Writing an IANA 739 Considerations Section in RFCs" [RFC5226], the following name spaces 740 are defined in ForCES SCTP TML. 742 o SCTP port 6704 for the HP channel, 6705 for the MP channel, and 743 6706 for the LP channel. 745 o SCTP Payload Protocol ID (PPID) 21 for the HP channel, 22 for the 746 MP channel, and 23 for the LP channel. 748 XXX [Note to IANA]: Port allocations(SCTP 6700-6702) were made in 749 August 2009. We have been asked by IESG to change these as 750 prescribed above. 752 7. Security Considerations 754 The SCTP TML provides the following security services to the PL: 756 o A mechanism to authenticate ForCES CEs and FEs at transport level 757 in order to prevent the participation of unauthorized CEs and 758 unauthorized FEs in the control and data path processing of a 759 ForCES NE. 761 o A mechanism to ensure message authentication of PL data and 762 headers transferred from the CE to FE (and vice-versa) in order to 763 prevent the injection of incorrect data into PL messages. 765 o A mechanism to ensure the confidentiality of PL data and headers 766 transferred from the CE to FE (and vice-versa), in order to 767 prevent disclosure of PL information transported via the TML. 769 Security choices provided by the TML are made by the operator and 770 take effect during the pre-association phase of the ForCES protocol. 771 An operator may choose to use all, some or none of the security 772 services provided by the TML in a CE-FE connection. 774 When operating under a secured environment, or for other operational 775 concerns (in some cases performance issues) the operator may turn off 776 all the security functions between CE and FE. 778 IP Security Protocol (IPsec) [RFC4301] is used to provide needed 779 security mechanisms. 781 IPsec is an IP level security scheme transparent to the higher-layer 782 applications and therefore can provide security for any transport 783 layer protocol. This gives IPsec the advantage that it can be used 784 to secure everything between the CE and FE without expecting the TML 785 implementation to be aware of the details. 787 The IPsec architecture is designed to provide message integrity and 788 message confidentiality outlined in the TML security requirements 790 [I-D.ietf-forces-protocol]. Mutual authentication and key exchange 791 protocol are provided by Internet Key Exchange (IKE)[RFC2409]. 793 7.1. IPsec Usage 795 A ForCES FE or CE MUST support the following: 797 o Internet Key Exchange (IKE)[RFC2409] with certificates for 798 endpoint authentication. 800 o Transport Mode Encapsulating Security Payload (ESP)[RFC4303]. 802 o HMAC-SHA1-96 [RFC2404] for message integrity protection 804 o AES-CBC with 128-bit keys [RFC3602] for message confidentiality. 806 o Replay protection[RFC4301]. 808 A compliant implementation SHOULD provide operational means for 809 configuring the CE and FE to negotiate other cipher suites and even 810 use manual keying. 812 7.1.1. SAD and SPD setup 814 To minimize the operational configuration it is RECOMMENDED that only 815 the IANA issued SCTP protocol number(132) be used as a selector in 816 the Security Policy Database (SPD) for ForCES. In such a case only a 817 single SPD and SAD entry is needed. 819 Setup MAY alternatively extend the above policy so that it uses the 3 820 SCTP TML port numbers as SPD selectors. But as noted above this 821 choice will require increased number of SPD entries. 823 In scenarios where multiple IP addresses are used within a single 824 association, and there is desire to configure different policies on a 825 per IP address, then it is RECOMMENDED to follow [RFC3554] 827 8. Acknowledgements 829 The authors would like to thank Joel Halpern, Michael Tuxen, Randy 830 Stewart, Evangelos Haleplidis, Chuanhuang Li, Lars Eggert, Avshalom 831 Houri, Adrian Farrel, Juergen Quittek, Magnus Westerlund, and Pasi 832 Eronen for engaging us in discussions that have made this document 833 better. 835 Ross Callon was an excellent manager who persevered in providing us 836 guidance and Joel Halpern was an excellent document shepherd without 837 whom this document would have taken longer to publish. 839 9. References 841 9.1. Normative References 843 [I-D.ietf-forces-protocol] 844 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 845 Khosravi, H., and W. Wang, "ForCES Protocol 846 Specification", draft-ietf-forces-protocol-22 (work in 847 progress), March 2009. 849 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 850 ESP and AH", RFC 2404, November 1998. 852 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 853 (IKE)", RFC 2409, November 1998. 855 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 856 Stewart, "On the Use of Stream Control Transmission 857 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 859 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 860 Algorithm and Its Use with IPsec", RFC 3602, 861 September 2003. 863 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 864 Conrad, "Stream Control Transmission Protocol (SCTP) 865 Partial Reliability Extension", RFC 3758, May 2004. 867 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 868 Internet Protocol", RFC 4301, December 2005. 870 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 871 RFC 4303, December 2005. 873 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 874 RFC 4960, September 2007. 876 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 877 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 878 May 2008. 880 9.2. Informative References 882 [I-D.ietf-forces-model] 883 Halpern, J. and J. Salim, "ForCES Forwarding Element 884 Model", draft-ietf-forces-model-16 (work in progress), 885 October 2008. 887 [I-D.ietf-tsvwg-sctpsocket] 888 Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. 889 Lei, "Sockets API Extensions for Stream Control 890 Transmission Protocol (SCTP)", 891 draft-ietf-tsvwg-sctpsocket-20 (work in progress), 892 January 2010. 894 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 895 of IP Control and Forwarding", RFC 3654, November 2003. 897 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 898 "Forwarding and Control Element Separation (ForCES) 899 Framework", RFC 3746, April 2004. 901 [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", 902 RFC 3768, April 2004. 904 Appendix A. Suggested SCTP TML Channel Work Implementation 906 As mentioned in Section 5, there are two levels of TML channel work 907 within an NE when a ForCES node (CE or FE) is connected to multiple 908 other ForCES nodes: 910 1. NE-level I/O work where a ForCES node (CE or FE) needs to choose 911 which of the peer nodes to process. 913 2. Node-level I/O work where a ForCES node, handles the three SCTP 914 TML channels separately for each single ForCES endpoint. 916 NE-level scheduling definition is left up to the implementation and 917 is considered out of scope for this document. Appendix A.4 discusses 918 briefly some constraints that an implementer needs to worry about. 920 This document and in particular Appendix A.1, Appendix A.2 and 921 Appendix A.3 discuss details of node-level I/O work. 923 A.1. SCTP TML Channel Initialization 925 As discussed in Section 5, it is recommended that the FE SHOULD do 926 socket connections to the CE in the order of incrementing priorities 927 i.e. LP socket first, followed by MP and ending with HP socket 928 connection. The CE, however, MUST NOT assume that there is ordering 929 of socket connections from any FE. Appendix B.1 has more details on 930 the expected initialization of SCTP channel work. 932 A.2. Channel work scheduling 934 This section provides high level details of the scheduling view of 935 the SCTP TML core (Section 4.2.1). A practical scheduler 936 implementation takes care of many little details (such as timers, 937 work quanta, etc) not described in this document. It is left to the 938 implementer to take care of those details. 940 The CE(s) and FE(s) are coupled together in the principles of the 941 scheduling scheme described here to tie together node overload with 942 transport congestion. The design intent is to provide the highest 943 possible robust work throughput for the NE under any network or 944 processing congestion. 946 A.2.1. FE Channel work scheduling 948 The FE scheduling, in priority order, needs to I/O process: 950 1. The HP channel I/O in the following priority order: 952 1. Transmitting back to the CE any outstanding result of 953 executed work via the HP channel transmit path. 955 2. Taking new incoming work from the CE which creates ForCES 956 work to be executed by the FE. 958 2. ForCES events which result in transmission of unsolicited ForCES 959 packets to the CE via the MP channel. 961 3. Incoming Redirect work in the form of control packets that come 962 from the CE via LP channel. After redirect processing, these 963 packets get sent out on external (to the NE) interface. 965 4. Incoming Redirect work in the form of control packets that come 966 from other NEs via external (to the NE) interfaces. After some 967 processing, such packets are sent to the CE. 969 It is worth emphasizing at this point again that the SCTP TML 970 processes the channel work in strict priority. For example, as long 971 as there are messages to send to the CE on the HP channel, they will 972 be processed first until there are no more left before processing the 973 next priority work (which is to read new messages on the HP channel 974 incoming from the CE). 976 A.2.2. CE Channel work scheduling 978 The CE scheduling, in priority order, needs to deal with: 980 1. The HP channel I/O in the following priority order: 982 1. Process incoming responses to requests of work it made to the 983 FE(s). 985 2. Transmitting any outstanding HP work it needs for the FE(s) 986 to complete. 988 2. Incoming ForCES events from the FE(s) via the MP channel. 990 3. Outgoing Redirect work in the form of control packets that get 991 sent from the CE via LP channel destined to external (to the NE) 992 interface on FE(s). 994 4. Incoming Redirect work in the form of control packets that come 995 from other NEs via external (to the NE) interfaces on the FE(s). 997 It is worth to repeat for emphasis again that the SCTP TML processes 998 the channel work in strict priority. For example, if there are 999 messages incoming from an FE on the HP channel, they will be 1000 processed first until there are no more left before processing the 1001 next priority work which is to transmit any outstanding HP channel 1002 messages going to the FE. 1004 A.3. SCTP TML Channel Termination 1006 Appendix B.2 describes a controlled disassociation of the FE from the 1007 NE. 1009 It is also possible for connectivity to be lost between the FE and CE 1010 on one or more sockets. In cases where SCTP multi-homing features 1011 are used for path availability, the disconnection of a socket will 1012 only occur if all paths are unreachable; otherwise, SCTP will ensure 1013 reachability. In the situation of a total connectivity loss of even 1014 one SCTP socket, it is recommended that the FE and CE SHOULD assume a 1015 state equivalent to ForCES Association Teardown being issued and 1016 follow the sequence described in Appendix B.2. 1018 A CE could also disconnect sockets to an FE to indicate an "emergency 1019 teardown". The "emergency teardown" may be necessary in cases when a 1020 CE needs to disconnect an FE but knows that an FE is busy processing 1021 a lot of outstanding commands (some of which the FE hasn't got around 1022 to processing yet). By virtue of the CE closing the connections, the 1023 FE will immediately be asynchronously notified and will not have to 1024 process any outstanding commands from the CE. 1026 A.4. SCTP TML NE level channel scheduling 1028 In handling NE-level I/O work, an implementation needs to worry about 1029 being both fair and robust across peer ForCES nodes. 1031 Fairness is desired so that each peer node makes progress across the 1032 NE. For the sake of illustration consider two FEs connected to a CE; 1033 whereas one FE has a few HP messages that need to be processed by the 1034 CE, another may have infinite HP messages. The scheduling scheme may 1035 decide to use a quota scheduling system to ensure that the second FE 1036 does not hog the CE cycles. 1038 Robustness is desired so that the NE does not succumb to a DoS attack 1039 from hostile entities and always achieves a maximum stable workload 1040 processing level. For the sake of illustration consider again two 1041 FEs connected to a CE. Consider FE1 as having a large number of HP 1042 and MP messages and FE2 having a large number of MP and LP messages. 1043 The scheduling scheme needs to ensure that while FE1 always gets its 1044 messages processed, at some point we allow FE2 messages to be 1045 processed. A promotion and preemption based scheduling could be used 1046 by the CE to resolve this issue. 1048 Appendix B. Suggested Service Interface 1050 This section outlines high level service interface between FEM/CEM 1051 and TML, the PL and TML, and between local and remote TMLs. The 1052 intent of this interface discussion is to provide general guidelines. 1053 The implementer is expected to care of details and even follow a 1054 different approach if needed. 1056 The theory of operation for the PL-TML service is as follows: 1058 1. The PL starts up and bootstraps the TML. The end result of a 1059 successful TML bootstrap is that the CE TML and the FE TML 1060 connect to each other at the transport level. 1062 2. Transmission and reception of the PL messages commences after a 1063 successful TML bootstrap. The PL uses send and receive PL-TML 1064 interfaces to communicate to its peers. The TML is agnostic to 1065 the nature of the messages being sent or received. The first 1066 message exchanges that happen are to establish ForCES 1067 association. Subsequent messages maybe either unsolicited events 1068 from the FE PL, control message redirects from/to the CE to/from 1069 FE, and configuration from the CE to the FE and their responses 1070 flowing from the FE to the CE. 1072 3. The PL does a shutdown of the TML after terminating ForCES 1073 association. 1075 B.1. TML Boot-strapping 1077 Figure 6 illustrates a flow for the TML bootstrapped by the PL. 1079 When the PL starts up (possibly after some internal initialization), 1080 it boots up the TML. The TML first interacts with the FEM/CEM and 1081 acquires the necessary TML parameterization (Section 4.2.1.6). Next 1082 the TML uses the information it retrieved from the FEM/CEM interface 1083 to initialize itself. 1085 The TML on the FE proceeds to connect the 3 channels to the CE. The 1086 socket interface is used for each of the channels. The TML continues 1087 to re-try the connections to the CE until all 3 channels are 1088 connected. It is advisable that the number of connection retry 1089 attempts and the time between each retry is also configurable via the 1090 FEM. On failure to connect one or more channels, and after the 1091 configured number of retry thresholds is exceeded, the TML will 1092 return an appropriate failure indicator to the PL. On success (as 1093 shown in Figure 6), a success indication is presented to the PL. 1095 FE PL FE TML FEM CEM CE TML CE PL 1096 | | | | | | 1097 | | | | | Bootup | 1098 | | | | |<-------------------| 1099 | Bootup | | | | | 1100 |----------->| | |get CEM info| | 1101 | |get FEM info | |<-----------| | 1102 | |------------>| ~ ~ | 1103 | ~ ~ |----------->| | 1104 | |<------------| | | 1105 | | |-initialize TML | 1106 | | |-create the 3 chans.| 1107 | | | to listen to FEs | 1108 | | | | 1109 | |-initialize TML |Bootup success | 1110 | |-create the 3 chans. locally |------------------->| 1111 | |-connect 3 chans. remotely | | 1112 | |------------------------------>| | 1113 | ~ ~ - FE TML connected ~ 1114 | ~ ~ - FE TML info init ~ 1115 | | channels connected | | 1116 | |<------------------------------| | 1117 | Bootup | | | 1118 | succeeded | | | 1119 |<-----------| | | 1120 | | | | 1122 Figure 6: SCTP TML Bootstrapping 1124 On the CE things are slightly different. After initializing from the 1125 CEM, the TML on the CE side proceeds to initialize the 3 channels to 1126 listen to remote connections from the FEs. The success or failure 1127 indication is passed on to the CE PL (in the same manner as was done 1128 in the FE). 1130 Post boot-up, the CE TML waits for connections from the FEs. Upon a 1131 successful connection by an FE, the CE TML level keeps track of the 1132 transport level details of the FE. Note, at this stage only 1133 transport level connection has been established; ForCES level 1134 association follows using send/receive PL-TML interfaces (refer to 1135 Appendix B.3 and Figure 8). 1137 B.2. TML Shutdown 1139 Figure 7 shows an example of an FE shutting down the TML. It is 1140 assumed at this point that the ForCES Association Teardown has been 1141 issued by the CE. It should also be noted that different 1142 implementations may have different procedures for cleaning up state 1143 etc. 1145 When the FE PL issues a shutdown to its TML for a specific PL ID, the 1146 TML releases all the channel connections to the CE. This is achieved 1147 by closing the sockets used to communicate to the CE. This results 1148 in the stack sending a SCTP shutdown which is received on the CE. 1150 FE PL FE TML CE TML CE PL 1151 | | | | 1152 | Shutdown | | | 1153 |----------->| | | 1154 | |-disconnect 3 chans. | | 1155 | |-SCTP level shutdown | | 1156 | |------------------------>| | 1157 | | | | 1158 | | |TML detects shutdown| 1159 | | |-FE TML info cleanup| 1160 | | |-optionally tell PL | 1161 | | |------------------->| 1162 | | | | 1163 | |- clean up any state of | | 1164 | |-channels disconnected | | 1165 | |<------------------------| | 1166 | |-SCTP shutdown ACK | | 1167 | | | | 1168 | Shutdown | | | 1169 | succeeded | | | 1170 |<-----------| | | 1171 | | | | 1173 Figure 7: FE Shutting down 1175 On the CE side, a TML disconnection would result in possible cleanup 1176 of the FE state. Optionally, depending on the implementation, there 1177 may be need to inform the PL about the TML disconnection. The CE 1178 stack level SCTP sends an acknowledgement to the FE TML in response 1179 to the earlier SCTP shutdown. 1181 B.3. TML Sending and Receiving 1183 The TML should be agnostic to the content of the PL messages, or 1184 their operations. The PL should provide enough information to the 1185 TML for it to assign an appropriate priority and loss behavior to the 1186 message. Figure 8 shows an example of a message exchange originated 1187 at the FE and sent to the CE (such as a ForCES association message) 1188 which illustrates all the necessary service interfaces for sending 1189 and receiving. 1191 When the FE PL sends a message to the TML, the TML is expected to 1192 pick one of HP/MP/LP channels and send out the ForCES message. 1194 FE PL FE TML CE TML CE PL 1195 | | | | 1196 |PL send | | | 1197 |----------->| | | 1198 | | | | 1199 | | | | 1200 | |-pick channel | | 1201 | |-TML Send | | 1202 | |------------->| | 1203 | | | | 1204 | | |-TML Receive on chan. | 1205 | | |- mux to PL/PL recv | 1206 | | |--------------------->| 1207 | | | ~ 1208 | | | ~ PL Process 1209 | | | ~ 1210 | | | PL send | 1211 | | |<---------------------| 1212 | | |-pick chan to send on | 1213 | | |-TML send | 1214 | |<-------------| | 1215 | |-TML Receive | | 1216 | |-mux to PL | | 1217 | PL Recv | | | 1218 |<---------- | | | 1219 | | | | 1221 Figure 8: Send and Recv Flow 1223 When the CE TML receives the ForCES message on the channel it was 1224 sent on, it demultiplexes the message to the CE PL. 1226 The CE PL, after some processing (in this example dealing with the 1227 FE's association), sends to the TML the response. And as in the case 1228 of FE PL, the CE TML picks the channel to send on before sending. 1230 The processing of the ForCES message upon arriving at the FE TML and 1231 delivery to the FE PL is similar to the CE side equivalent as shown 1232 above in Appendix B.3. 1234 Authors' Addresses 1236 Jamal Hadi Salim 1237 Mojatatu Networks 1238 Ottawa, Ontario 1239 Canada 1241 Email: hadi@mojatatu.com 1243 Kentaro Ogawa 1244 NTT Corporation 1245 3-9-11 Midori-cho 1246 Musashino-shi, Tokyo 180-8585 1247 Japan 1249 Email: ogawa.kentaro@lab.ntt.co.jp