idnits 2.17.1 draft-ietf-forces-tcptml-04.txt: -(299): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(481): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(813): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(852): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(870): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(883): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(886): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1260. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 38 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 16) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([15], [3], [4], [5], [6], [9], [SoftCOM2004]), 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 799: '... the CEs and FEs MUST be established b...' RFC 2119 keyword, line 808: '...points that implement TLS MUST perform...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 133 has weird spacing: '... define both ...' == Line 138 has weird spacing: '...ultiple trans...' == Line 140 has weird spacing: '... will take ...' == Line 908 has weird spacing: '... in chann...' == Line 909 has weird spacing: '... in initA...' == (19 more instances...) ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [2], but that reference does not seem to mention RFC 2119 either. -- 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 (July 2006) is 6494 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 section? '2' on line 47 looks like a reference -- Missing reference section? '3' on line 340 looks like a reference -- Missing reference section? '5' on line 330 looks like a reference -- Missing reference section? '4' on line 148 looks like a reference -- Missing reference section? '9' on line 269 looks like a reference -- Missing reference section? '6' on line 805 looks like a reference -- Missing reference section? '15' on line 822 looks like a reference -- Missing reference section? 'ICCCN 2004' on line 891 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Hormuzd Khosravi 3 Internet Draft Shuchi Chawla 4 Document: draft-ietf-forces-tcptml-04.txt Intel Corp. 5 Expires: January 2007 Furquan Ansari 6 Working Group: ForCES Lucent Tech. 7 Jon Maloy 8 Ericsson 10 July 2006 12 TCP/IP based TML (Transport Mapping Layer) for ForCES protocol 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as ``work in 30 progress.'' 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Conventions used in this document 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 46 this document are to be interpreted as described in [2]. 48 Abstract 49 This document defines the IP based TML (Transport Mapping Layer) for 50 the ForCES protocol. It explains the rationale for choosing the 51 transport protocols and also describes how this TML addresses all 52 the requirements described in the Forces [3] requirements and 53 ForCES protocol [5] document. 55 Table of Contents 57 1. Definitions.....................................................3 58 2. Introduction....................................................3 59 3. Protocol Framework Overview.....................................4 60 3.1.1. The PL layer................................................5 61 3.1.2. The TML layer...............................................5 62 4. TML Overview....................................................5 63 4.1. Rationale for using TCP and DCCP..............................6 64 4.2. Separate Control and Data channels............................6 65 4.3. Reliability...................................................8 66 4.4. Congestion Control............................................8 67 4.5. Security......................................................8 68 4.6. Addressing....................................................8 69 4.7. Prioritization................................................9 70 4.8. HA Decisions..................................................9 71 4.9. Encapsulations Used..........................................10 72 5. TML Messaging..................................................10 73 6. TML Interface to Upper layer Protocol..........................10 74 6.1. TML Service Interface Overview...............................10 75 6.2. Protocol Initialization and Shutdown Model...................11 76 6.2.1. Protocol Initialization....................................11 77 6.2.2. Protocol Shutdown..........................................13 78 6.3. Multicast Model..............................................14 79 6.4. Broadcast Model..............................................17 80 7. Security Considerations........................................17 81 7.1. TLS Usage for Securing TML...................................17 82 7.2. IPSec Usage for securing TML.................................18 83 8. IANA Considerations............................................18 84 9. Manageability..................................................18 85 10. References....................................................18 86 10.1. Normative References........................................18 87 10.2. Informative References......................................18 88 11. Acknowledgments...............................................19 89 Appendix A. TML Service Interface................................19 90 A.1. TML Initialize.............................................19 91 A.2. TML Channel Open...........................................20 92 A.3. TML Channel Close..........................................21 93 A.4. TML Channel Write..........................................22 94 A.5. TML Channel Read...........................................23 95 A.6. TML Multicast Group Join...................................25 96 A.7. TML Multicast Group Leave..................................25 97 Authors' Addresses...............................................26 99 1. 100 Definitions 102 The following definitions are taken from [3], [5] 104 ForCES Protocol - While there may be multiple protocols used within 105 the overall ForCES architecture, the term "ForCES protocol" refers 106 only to the protocol used at the Fp reference point in the ForCES 107 Framework in RFC3746 [4]. This protocol does not apply to 108 CE-to-CE communication, FE-to-FE communication, or to communication 109 between FE and CE managers. Basically, the ForCES protocol works in 110 a master-slave mode in which FEs are slaves and CEs are masters. 112 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 113 architecture that defines the ForCES protocol messages, the protocol 114 state transfer scheme, as well as the ForCES protocol architecture 115 itself (including requirements of ForCES TML (see below)). 116 Specifications of ForCES PL are defined by this document. 118 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 119 ForCES protocol architecture that specifically addresses the 120 protocol message transportation issues, such as how the protocol 121 messages are mapped to different transport media (like TCP, IP, ATM, 122 Ethernet, etc), and how to achieve and implement reliability, 123 multicast, ordering, etc. This document defines an IP based ForCES 124 TML. 126 2. 127 Introduction 129 The ForCES (Forwarding and Control Element Separation) working group 130 in the IETF is defining the architecture and protocol for separation 131 of control and forwarding elements in network elements such as 132 routers. [3 133 .], [4] define both architectural and protocol 134 requirements for the communication between CE and FE. The ForCES 135 protocol layer [5] describes the protocol specification. It is 136 envisioned that the ForCES protocol would be independent of the 137 interconnect technology between the CE and FE and can run over 138 multiple transport technologies and protocol. Thus a Transport 139 Mapping Layer (TML) has been defined in the protocol framework that 140 will take care of mapping the protocol messages to specific 141 transports. This document defines the IP based TML for the ForCES 142 protocol layer. It also addresses all the requirements for the TML 143 including security, reliability, etc. 145 3. 146 Protocol Framework Overview 148 The reader is referred to the Framework document [4], and in 149 particular sections 3 and 4, for architectural overview and where 150 and how the ForCES protocol fits in. There may be some content 151 overlap between the ForCES protocol draft [5] and this section in 152 order to provide clarity. 154 The ForCES protocol constitutes two pieces: the PL and TML layer. 155 This is depicted in Figure 1 below. 157 +------------------------------------------------ 158 | CE PL layer | 159 +------------------------------------------------ 160 | CE TML layer | 161 +------------------------------------------------ 162 ^ 163 | 164 ForCES | (i.e. Forces data + control 165 PL | packets ) 166 messages | 167 over | 168 specific | 169 TML | 170 encaps | 171 and | 172 transport | 173 | 174 v 175 +------------------------------------------------ 176 | FE TML layer | 177 +------------------------------------------------ 178 | FE PL layer | 179 +------------------------------------------------ 181 Figure 1: ForCES Interface 183 The PL layer is in fact the ForCES protocol. Its semantics and 184 message layout are defined in [5]. The TML Layer is necessary to 185 connect two ForCES PL layers as shown in Figure 1 above. 187 Both the PL and TML layers are standardized by the IETF. While only 188 one PL layer is defined, different TMLs are expected to be 189 standardized. To interoperate the TML layer at the CE and FE are 190 expected to be of the same definition. 192 On transmit, the PL layer delivers its messages to the TML layer. 193 The TML layer delivers the message to the destination TML layer(s). 194 On reception, the TML delivers the message to its destination PL 195 layer(s). 197 3.1.1.The PL layer 199 The PL is common to all implementations of ForCES and is 200 standardized by the IETF [5]. The PL layer is responsible for 201 associating an FE or CE to an NE. It is also responsible for 202 tearing down such associations. An FE uses the PL layer to throw 203 various subscribed-to events to the CE PL layer as well as respond 204 to various status requests issued from the CE PL. The CE configures 205 both the FE and associated LFBs attributes using the PL layer. In 206 addition the CE may send various requests to the FE to activate or 207 deactivate it, reconfigure it�s HA parameterization, subscribe to 208 specific events etc. 210 3.1.2.The TML layer 212 The TML layer is essentially responsible for transport of the PL 213 layer messages. The TML is where the issues of how to achieve 214 transport level reliability, congestion control, multicast, 215 ordering, etc. are handled. All TMLs will deliver a standard set of 216 services and capabilities to the PL; the PL may use any available 217 TML. The different TMLs each could implement things differently 218 based on capabilities of underlying media and transport. 219 However, since all TMLs will support a standardized interface, 220 interoperability is guaranteed as long as both endpoints support the 221 same TML. All ForCES Protocol Layer implementations should be 222 portable across all TMLs, because all TMLs have the same top edge 223 semantics. 225 4. 226 TML Overview 228 The TML consists of two connections between the CE and FE over which 229 the protocol messages are exchanged. One of the connections is 230 called the control channel, over which control messages are 231 exchanged, the other is called data channel over which external 232 protocol packets, such as routing packets will be exchanged. The 233 control channel is a TCP connection; the data channel is a DCCP 234 connection. The TCP and DCCP connections will use unique server 235 port numbers for each of the channels. In addition to this, this TML 236 will provide mechanisms to prioritize the messages over the 237 different channels. 239 Some of the rationale for choosing these transport mechanisms as 240 well as explanation of how they meet the TML requirements is 241 explained below. The ForCES protocol defines requirements to be met 242 by the TML. However, the requirements in the draft do not always 243 differentiate between control versus data messaging. The assumption 244 is that the requirements for messaging over the data channel are a 245 subset of those specified for control messaging. When such an 246 assumption is made, it is explicitly specified and the justification 247 for the same stated. 249 4.1.Rationale for using TCP and DCCP 251 For control messaging, TCP meets all the reliability requirements 252 (no losses, no data corruption, no re-ordering of data) for the 253 ForCES protocol/TML and also provides congestion control mechanism, 254 which is important to meet the scalability requirement. In addition, 255 it helps with interoperability since TCP is a well-understood, 256 widely deployed transport protocol. Using TCP also enables this TML 257 and the protocol to work seamlessly in single hop and multihop 258 scenarios. 260 The reliability requirements for the data channel messages are 261 different from that of the control messages [3] i.e. they don�t 262 require strict reliability in terms of retransmission, etc. However 263 congestion control is important for the data channel because in case 264 of DoS attacks, if an unreliable transport such as UDP is used for 265 the data traffic, it can more easily overflow the physical 266 connection, overwhelming the control traffic with congestion. Thus 267 we need a transport protocol that provides congestion control but 268 does not necessarily provide full reliability. Datagram Congestion 269 Control Protocol (DCCP) [9], which is on the RFC track is a 270 transport protocol that exactly meets this requirement. 272 4.2.Separate Control and Data channels 274 The ForCES NEs are subject to Denial of Service (DoS) attacks 275 [Requirements Section 7 #15]. A malicious system in the network can 276 flood a ForCES NE with bogus control packets such as spurious RIP or 277 OSPF packets in an attempt to disrupt the operation of and the 278 communication between the CEs and FEs. In order to protect against 279 this situation, the TML uses separate control and data channels for 280 communication between the CEs and FEs. Figure 2 below illustrates 281 the different communication channels between the CEs and the FEs. As 282 an example, the communication channels for support of High 283 Availability with redundant CEs are also included. The setup of 284 these channels would be dependent on the High Availability model 285 used in the NE. 287 ACTIVE CE STANDBY CE 288 +-------------------+ +-------------------+ 289 | CE: PL | | CE: PL | 290 +-------------------+ +-------------------+ 291 | CE: TML | | CE: TML | 292 +-------------------+ +-------------------+ 293 | CE: TCP/DCCP | | CE: TCP/DCCP | 294 +-------------------+ +-------------------+ 295 | | | | | | | | | | 296 | . | . | . | . | . 297 | | | | | | | | | | 298 | . | . | . | . | . 299 | | | | | | Cc1� Cd1� Cc2� Cd2�Ccn� Cdn� 300 | . | . | . 301 +-Cc1-----+ | | | | +-.-.-.-.-.Cdn.-+ 302 | +-Cd1-.-.+ | . +--------Ccn---+ | 303 | | | | | . 304 | . +Cc2+ . | | 305 | | | +Cd2+ | . 306 | . | | | | 307 +------------+ +------------+ +------------+ 308 |FE: TCP/DCCP| |FE: TCP/DCCP| . . . |FE: TCP/DCCP| 309 +------------+ +------------+ +------------+ 310 | FE: TML | | FE: TML | | FE: TML | 311 +------------+ +------------+ +------------+ 312 | FE: PL | | FE: PL | | FE: PL | 313 +------------+ +------------+ +------------+ 314 FE1 FE2 FEn 315 \-------------V------------/ 316 FE 1+1 Redundancy 318 Legend: 319 ---- Cc# : Unicast Control Channel between Active CE and FE# 320 -.-. Cd# : Unicast Data Channel between Active CE and FE# 322 ---- Cc#�: Unicast Control Channel between Standby CE and FE# 323 -.-. Cd#�: Unicast Data Channel between Standby CE and FE# 325 Figure 2: CE-FE Communication Channels 327 The data channel carries IP packets from the network needed by the 328 CE, such as RIP, OSPF packets as outlined in Requirements [3] 329 Section 7 #10, which are carried in ForCES Packet Redirect messages 330 [5], between the CEs and FEs. All the other ForCES messages, which 331 are used for configuration/capability exchanges, event notification, 332 etc, are carried over the control channel. The data channel is set 333 up only after the control channel is set up. 335 4.3.Reliability 337 TCP provides the reliability (no losses, no data corruption, no re- 338 ordering of data) required for ForCES protocol control messages. 340 As mentioned earlier, as per [3], strict reliability is not a 341 requirement for payload carried over the data channel. Hence, the 342 use of DCCP is adequate for the data channel. 344 4.4.Congestion Control 346 TCP provides congestion control needed to satisfy this requirement 347 for the control channel. 349 DCCP provides congestion control to satisfy this requirement for the 350 data channel. DCCP supports two congestion control mechanisms � TCP 351 like congestion control specified with a CCID of 2 and TFRC 352 congestion control specified with a CCID of 3. The DCCP channel may 353 use either of these mechanisms; the CE and the FE may be configured 354 with the mechanism to be used. The default CCID to be used if none 355 is configured is CCID 2 which provides TCP like congestion control. 357 4.5.Security 359 The TML channel can be secured in multiple ways. The default mode is 360 to support the �no security�, a mode that is commonly used when it 361 is determined that securing the ForCES channel is not needed (e.g. 362 closed-box scenario). For scenarios where security is important, the 363 TML uses either the TLS [6] or the IPSec [15] mechanisms to secure 364 the channel(s). The security mode selection is normally done through 365 configuration on either ends. Note that the TML will operate 366 correctly only when both the ends are configured with the same 367 security mechanism. The security mode used by the CE and FE is 368 dependent on the deployment scenario as per the ForCES protocol 369 requirements draft [3 370 .]. Please see section 7 on security 371 considerations for more details. 373 4.6.Addressing 375 This TML uses addressing provided by IP layer. 377 For unicast addressing/delivery of control messages, it uses the TCP 378 connection between the CE and FE. For multicast/broadcast 379 addressing/delivery of control messages, this TML uses multiple TCP 380 connections between the CE and FEs. 382 Additionally, the TML layer maintains the mapping between the PL 383 layer addresses and the channel descriptors assigned by the TML 384 layer. The PL layer is unaware of these descriptors; the PL layer 385 only uses the PL layer addresses for all communication with the TML 386 layer. 388 For unicast addressing/delivery over the data channel, it uses the 389 DCCP connection between the CE and FE. Multicast/broadcast 390 addressing and delivery is not supported over the data channel; data 391 messages may only be sent from the CE to the FEs using unicast 392 FEIds. If multicast support is required, the higher level protocol 393 being carried over the data channel is responsible for it. 395 4.7.Prioritization 397 This TML provides prioritization of messages sent over control 398 channel as compared to the data channel. This has also been found to 399 be useful in face of DoS attacks on the protocol. Additionally the 400 TML can support multiple levels of prioritization for control 401 messages if it supports a multi-queue strategy. The scheduling 402 algorithm used at the TML layer would give preferential treatment to 403 higher priority messages. The scheduling algorithm used in the TML 404 layer is implementation dependent. 406 4.8.HA Decisions 408 The TML transports the heartbeat messages generated at the PL layer 409 to detect liveness of the CE/FE. The TML does not generate any 410 heartbeat messages of its own. The PL heartbeat messages are 411 carried over the control channel. For the data channel, the TML will 412 propagate any DCCP detected connectivity issues over the channel to 413 the PL layer. If the PL wishes to actively monitor the data 414 channel, it may do so by sending periodic redirect packets from the 415 CE to the FE. This details of this mechanism are however outside 416 the scope of the TML. 418 TML is responsible for keeping the control and data communication 419 channels up. It however does not have the authority to decide which 420 CE to set up the channels with. That is outside its control. 422 If a FE-CE communication channel goes down or connectivity is lost, 423 the following steps are taken by the TML layer: 424 - FE TML attempts to reestablish the communication channel 425 - If the FE TML is unable to reestablish the channel (after some 426 configured number of retries/timeout), it notifies the FE PL that 427 the channel is down. 428 - CE TML waits for the channel to be reestablished (since only the 429 FE can reestablish it) for some configured timeout prior to 430 notifying the CE PL that the channel is down. Alternatively, the 431 PL may detect the channel is down via the use of the PL generated 432 heartbeat messages. 434 If the control channel or data channel goes down, PL will control 435 initiation of a failover to a new CE � both control and data 436 channels will be reestablished with the new CE. 438 If an FE goes down and a standby FE exists for it, and it has 439 communication channels set up with the CE, the CE PL may start to 440 use the channels associated with the standby FE. This is not within 441 the scope of TML itself, but falls in the scope of High 442 Availability. 444 4.9.Encapsulations Used 446 There is no further message encapsulation of control and data 447 messages done at the TML layer. The PL generated control messages 448 are transported as is by the TML layer. The ForCES protocol control 449 messages are encapsulated with a TCP/IP header. The PL data messages 450 carried over the data channel are encapsulated in a DCCP header. 452 5. 453 TML Messaging 455 There is no TML layer messaging. TML only transports messages from 456 the PL layer. 458 6. 459 TML Interface to Upper layer Protocol 461 ForCES TML interfaces with an upper layer protocol, the PL Layer and 462 a lower layer protocol, TCP (in the case of TCP TML). This section 463 defines the interface to the upper layer protocol. This interface 464 should be used only as a guideline in implementing the API. 465 Additionally, although the current interface is defined mainly as a 466 synchronous interface, the interface may be implemented to be 467 asynchronous if desired. 469 6.1.TML Service Interface Overview 471 This section provides an overview of the TML service interface to 472 help with understanding the following sections on protocol behavior 473 with respect to initialization and multicast support. Note that 474 this is just a brief overview for understanding the protocol 475 initialization/shutdown sequences. It is by no means complete; the 476 complete service interface is being specified in a separate draft. 477 More details on this interface are specified in Appendix A. 479 tmlInit() � Enables establishment of communication channels 481 tmlOpen() � Opens one or more communication channels for control and 482 data messaging 484 tmlClose() � Closes one or more communication channels used for 485 control and data messaging 487 tmlWrite() � Write messages to a specific CE or FE 489 tmlRead() � Read messages from a specific CE or FE 491 tmlMulticastGroupJoin() � Request an FE to join a multicast group 493 tmlMulticastGroupLeave() - Request an FE to leave a multicast group 495 6.2.Protocol Initialization and Shutdown Model 497 In order for the peer PL Layers to communicate, the control and data 498 channels must be setup. This section defines a model for the setup 499 of the channels, using the TML interface defined above. In this 500 model, the peer TML Layers may establish the control and data 501 channels between the FE and the CE without the involvement of the PL 502 Layers, or if desired, the PL Layer may trigger the setup of the 503 channels; this is left as an implementation decision. Both modes 504 may also be supported within an implementation. 506 6.2.1.Protocol Initialization 508 The control channel must be established between the FE TML and the 509 CE TML for establishment of association to proceed. This channel 510 will be used for messages related to the association setup and 511 capability query. The data channel must be established no later 512 than the response from the FE to the CE Topology query message. The 513 following are the significant aspects associated with channel setup: 514 - A single call by the PL layer sets up the communication channels 515 for both control and data messaging to a specific FE. The call 516 specifies Unicast CE Id and attributes for control and data 517 channels. 518 - It is up to the TML layer whether to set up a single channel for 519 both control and data or distinct channels for control and data 521 - TML sets up the appropriate channels and allocates required 522 descriptors for the channels. TML layer maintains a mapping 523 between the Unicast FE/CE Id and the channel descriptors and 524 channel type (control versus data) it creates once the FEId/CEId 525 is known. 526 - There is no need for channel descriptors to be returned to the PL 527 layer at either the FE or the CE. PL Layer only uses the Unicast 528 FE/CE Id for read/write calls and specifies the type of message 529 (control versus data) to be read/written. 530 - If only one of the channels is setup successfully, the TML layer 531 will have to return appropriate status that specifies which 532 channel is setup successfully and which isn�t. 534 Figure 4 illustrates the initialization model where the PL layer via 535 an interface provided by the TML Layer, triggers the setup of the 536 control and data channels. 538 FE1 PL FE1 TML CE TML CE PL 539 | | | | \ 540 / | | | tmlInit() | | 541 FE | | | |<--------------| > CE Init/ 542 Init/ < | | | | | Bootup 543 Bootup | | | | | / 544 \ | | | | 545 | tmlOpen(CeId) | | | 546 |-------------->| | | \ 547 | |CtrlChan(Cc) Setup | | | Setup control 548 | |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not 549 | | | > already setup 550 | |CtrlChan(Cc) Setup Rsp | | | 551 | |<~~~~~~~~~~~~~~~~~~~~~~| | | 552 | CeId . [CcDes] | | | 553 | | | / 554 | | | | 555 | |DataChan(Cd) Setup | | | Setup data 556 | |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not 557 | | | | > already setup 558 | |DataChan(Cd) Setup Rsp | | | 559 | |<~~~~~~~~~~~~~~~~~~~~~~| | | 560 | CeId . [CcDes, | | | 561 | | CdDes] | | / 562 | | | | 563 | <-- status | | | 564 | | | | 565 |tmlEvent(ChUp) | |tmlEvent(ChUp) | 566 |<--.--.--.--.--| |--.--.--.--.-->| 567 | | | | 568 | | Asso Setup Req | | 569 |---------------|-----------------------|-------------->| 570 | FeId . [CcDes, | \ 571 | CdDes] | | TML updates 572 | | > its mappings 573 | | | once FEId is 574 | | Asso Setup Rsp | | | available. 575 |<--------------|-----------------------|---------------| / 576 | | | | 577 | | Capability Query | | 578 |<--------------|-----------------------|---------------| 579 | | Capability Query Rsp | | 580 |---------------|-----------------------|-------------->| 581 | | | | 582 | | Topology Query | | 583 |<--------------|-----------------------|---------------| 584 | | Topology Query Rsp | | 585 |---------------|-----------------------|-------------->| 586 | | | | 587 | |STEADY STATE OPERATION | | 588 |<--------------|-----------------------|-------------->| 589 | | | | 590 Legend: 591 PL --------> PL : Protocol layer messaging 592 PL --------> TML: TML API 593 TML --.--.--> PL : Events/Notifications/Upcalls 594 TML ~~~~~~~~> TML: Internal protocol communication 596 Figure 4: Protocol Initialization (Channel Setup) 598 6.2.2.Protocol Shutdown 600 The control channel teardown must occur only after the association 601 teardown has occurred. The data channel teardown may occur no earlier 602 than the association teardown. 604 The PL Layer may shutdown control and data channels via invocation of 605 the tmlClose() API. When the PL layer shuts down the channels, the 606 channels are torn down; hence ForCES messaging between the CE and FE is 607 no longer possible over those channels. A tmlClose() results in both 608 control and data channels (regardless of whether they are implemented 609 as a single channel or distinct channels in the TML layer) being 610 shutdown; it is not possible to close just one of them. A subsequent 611 tmlOpen() triggers establishment of the channel. The channel(s) may be 612 shutdown by either the FE or the CE. If an FE initiates the shutdown, 613 it specifies the CE Id associated with the channel(s) to be shutdown. 614 If a CE initiates the shutdown, it specifies the FE Id associated with 615 the channel(s) to be shutdown. A channel shutdown by the FE is 616 illustrated in Figure 5 and a channel shutdown by the CE is illustrated 617 in Figure 6. 619 FE PL FE TML CE TML CE PL 620 | | | | 621 | |STEADY STATE OPERATION | | 622 |<--------------|-----------------------|-------------->| 623 | | Config Request | | 624 |<--------------|-----------------------|---------------| 625 | | Config Response | | 626 |---------------|-----------------------|-------------->| 627 | | | | 628 | | Association Teardown | | 629 |<--------------|-----------------------|---------------| 630 | | | | 631 | | | | \ 632 |tmlClose(CeId) | | | | FE initiated: 633 |-------------->| | | > FE specifies CE 634 | <-- status | | | | Id associated 635 | | | | / with channel. 637 Legend: 638 PL --------> PL : Protocol layer messaging 639 PL --------> TML: TML API 640 TML --.--.--> PL : Events/Notifications/Upcalls 641 TML ~~~~~~~~> TML: Internal protocol communication 643 Figure 5: Protocol Shutdown: FE Initiated 645 FE PL FE TML CE TML CE PL 646 | | | | 647 | |STEADY STATE OPERATION | | 648 |<--------------|-----------------------|-------------->| 649 | | Config Request | | 650 |<--------------|-----------------------|---------------| 651 | | Config Response | | 652 |---------------|-----------------------|-------------->| 653 | | | | 654 | | Association Teardown | | 655 |<--------------|-----------------------|---------------| 656 | | | | 657 | | | | \ 658 | | |tmlClose(FeId) | | CE initiated: 659 | | |<--------------| > FE specifies CE 660 | <-- status | | status --> | | Id associated 661 | | | | / with channel. 663 Legend: 664 PL --------> PL : Protocol layer messaging 665 PL --------> TML: TML API 666 TML --.--.--> PL : Events/Notifications/Upcalls 667 TML ~~~~~~~~> TML: Internal protocol communication 669 Figure 6: Protocol Shutdown: CE Initiated 671 6.3.Multicast Model 672 The TML layer provides support for multicast of control messages. 673 In the ForCES model, support is required to multicast to the FEs 674 from a CE; in this case, the CE is the source or root of the 675 multicast and the FEs are the leaves. 677 Support for multicast requires that a channel for supporting 678 multicast be opened between an FE and the CE. In the case of TCP 679 TML, the same channel is used for both unicast and multicast 680 messaging since multicast mode is simulated using unicast channels 681 in this case. Once the channel is open, a CE may request FEs to join 682 and leave specified multicast groups. Multicast support is CE- 683 initiated. FEs can join a multicast group only if the CE requests 684 them to join the group. TML maintains the mapping between PL layer 685 IDs and channel descriptors for multicast. The following are the 686 significant steps for adding or removing members from a multicast 687 group: 689 - CE PL communicates with FE PL for requesting the FE to join or 690 leave a multicast group. 691 - FE PL informs FE TML regarding the join or leave request. 692 - FE TML updates the multicast group information. It updates the 693 mapping between the FE Multicast Id and the channel descriptor to 694 be used for multicast for that FE. This mapping may be from 695 [Multicast FE Id] . [FE Id] . [Channel descriptor] or directly 696 from [Multicast FE Id] . [Channel descriptor]. This is 697 implementation dependent. 698 - FE PL responds to CE PL informing it of the status of the join or 699 leave request. 700 - If the join or leave request was successful, CE PL informs CE TML 701 regarding the update to the multicast group membership. 702 - CE TML updates the multicast group membership. It updates the 703 mapping between the FE Multicast Id and the set of channel 704 descriptors to be used for multicast to the FEs that are members 705 of this group. This mapping may be from [Multicast FE Id] . [Set 706 of FE Ids] . [Set of channel descriptors] or directly from 707 [Multicast FE Id] . [Set of channel descriptors]. This is 708 implementation dependent. 709 - There is no need for any descriptors to be returned to the PL 710 layer at either the FE or the CE. PL Layer only uses the 711 Multicast FE Id for write calls and specifies the type of message 712 (control versus data) to be written. 714 A tmlWrite() on a unicast FE Id results in a unicast message being 715 sent to the FE associated with the channel. A tmlWrite() on a 716 multicast FE Id results in multicast messaging. Figures 7 and 8 717 illustrate multicast scenarios with 2 FEs, FE1 and FE2. In Figure 718 7, the CE requests FE1 to join a multicast group. Although not 719 shown as a separate figure, if FE2 were to join the same group, the 720 join procedure would be the same as in Figure 7; it would result in 721 the multicast group membership being updated at the TML layer on the 722 CE to include FE2 in the group. In Figure 8, the CE requests FE1 to 723 leave the multicast group, thus resulting in only FE2 being a member 724 of the multicast group. 726 Multicast Scenario with FE1 joining group: New group created 728 FE1 PL FE1 TML CE TML CE PL 729 | | | | 730 | | | | \ 731 | MC Grp Join Req (McId) | | 732 |<--------------|-------------------|---------------| | CE:PL Level multicast group 733 [TML | tmlJoin(McId) | | | | join request sent to each 734 updates |-------------->| | | | FE:PL that needs to be part 735 MC grp | McId = {FE1_ChDes} | | > of a multicast group, McId, 736 info] | | | | | where McId specifies a 737 | <-- status | | | | multicast group Id at the 738 | | | | | PL layer. 739 | MC Grp Join Rsp (status) | | 740 |---------------|-------------------|-------------->| / 741 | | | | 742 | | | | \ 743 | | |tmlJoin(McId) | | TML updates multicast 744 | | |<--------------| | group membership. PL is 745 | | McId = {FE1_ChDes} | > only aware of PL layer 746 | | | | | multicast group Id, that is, 747 | | | status --> | | McId] 748 | | | | / 750 Figure 7: Multicast Support: FE1 Joins Group 752 Multicast Scenario with FE1 leaving group: Group membership updated 753 to exclude FE1 755 FE1 PL FE1 TML CE TML CE PL 756 | | | | 757 | | | | \ 758 | MC Grp Leave Req (McId, FE1) | | 759 |<--------------|-------------------|---------------| | CE:PL Level multicast group 760 [TML | tmlLeave(McId)| | | | leave request sent to FE1:PL 761 removes |-------------->| | | | that needs to be removed 762 MC grp | McId = {} | | > from multicast group, McId, 763 info] | | | | | where McId specifies a 764 | <-- status | | | | multicast group Id at the 765 | | | | | PL layer. 766 | MC Grp Leave Rsp (status) | | 767 |---------------|-------------------|-------------->| / 768 | | | | 769 | | | | \ 770 | | |tmlLeave(McId) | | TML removes FE1 from 771 | | |<--------------| | multicast group McId. 772 | | McId = {FE2_ChDes} | > That leaves only FE2 773 | | | | | in the group. 774 | | | status --> | | 775 | | | | / 777 Figure 8: Multicast Support: FE1 Leaves Group 779 6.4.Broadcast Model 781 The TML layer provides support for broadcast of control messages. 782 In the ForCES model, support is required to broadcast to the FEs 783 from a CE. The broadcast model is just a special case of multicast, 784 where all FEs are included. This TML does not support CE or NE 785 broadcast. 787 7. 788 Security Considerations 790 If the CE or FE are in a single box and network operator is running 791 under a secured environment then it is up to the network 792 administrator to turn off all the security functions. This is 793 configured during the pre-association phase of the protocol. This 794 mode is called �no security� mode of operation. 796 When the CEs, FEs are running over IP networks or in an insecure 797 environment, the operator has the choice of configuring either TLS 798 [6] or IPSec [15] to provide security. The security association 799 between the CEs and FEs MUST be established before any ForCES 800 protocol messages are exchanged between the CEs and FEs. 802 7.1.TLS Usage for Securing TML 804 This section is applicable for CE or FE endpoints that use the TML 805 with TLS [6] to secure communication. 807 Since CE is master and FEs are slaves, the FEs are TLS clients and 808 CEs are TLS server. The endpoints that implement TLS MUST perform 809 mutual authentication during TLS session establishment process. CE 810 must request certificate from FE and FE needs to pass the requested 811 information. 813 We recommend �TLS-RSA-with-AES-128-CBC-SHA� cipher suite, but CE or 814 FE may negotiate other TLS cipher suites. With this TML, TLS is used 815 only for the control channel while the data channel is left 816 unsecured since the data packets (e.g. routing protocol packets) may 817 contain their own security mechanisms. Further, TLS has not yet been 818 defined for usage with DCCP. 820 7.2.IPSec Usage for securing TML 821 This section is applicable for CE or FE endpoints that use the TML 822 with IPSec [15] to secure their respective communication. IPSec is 823 transparent to the higher-layer applications and can provide 824 security for any transport layer protocol. This mechanism is can be 825 used to secure just the control or both the control and the data 826 channel simultaneously. 828 8. 829 IANA Considerations 831 This TML needs to have a one well-defined TCP port number for 832 control messaging, which needs to be assigned by IANA. The control 833 port is referred to as the TCP_TML_CONTROL_PORT. Similarly, TML 834 requires one well-defined DCCP port number for data messaging. This 835 data port is referred to as the DCCP_TML_DATA_PORT. 837 9. 838 Manageability 840 TBD 842 10. 843 References 844 10.1.Normative References 846 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 847 October 1996. 849 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 850 Levels", RFC2119 (BCP), IETF, March 1997. 852 3. Khosravi, et al., ��Requirements for Separation of IP Control and 853 Forwarding�, RFC 3654, November 2003. 855 4. L. Yang, et al., � ForCES Architectural Framework�, RFC 3746, 856 April 2004. 858 5. A. Doria, et al., �ForCES protocol specification�, draft-ietf- 859 forces-protocol-06.txt, December 2005. 861 10.2.Informative References 863 6. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. 864 Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 866 7. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 867 Security over Stream Control Transmission Protocol", RFC 3436, 868 December 2002. 870 8. R. Stewart, et al., �Stream Control Transmission Protocol (SCTP)�, 871 RFC 2960, October 2000. 873 9. E. Kohler, M. Handley, S. Floyd, J. Padhye, �Datagram Congestion 874 Control Protocol (DCCP)�, draft-ietf-dccp-spec-13.txt, December 875 2005. 877 10.Floyd, S., �Congestion Control Principles�, RFC 2914, September 878 2000. 880 11.A. Doria, F. Hellstrand, K. Sundell, T. Worster, �General Switch 881 Management Protocol (GSMP) V3�, RFC 3292, June 2002. 883 12.H. Balakrishnan, et al. �The Congestion Manager�, RFC 3124, June 884 2001. 886 13.H. Khosravi, S. Lakkavali, �Analysis of protocol design issues for 887 open standards based programmable routers and switches� [SoftCOM 888 2004] 890 14.S. Lakkavali, H. Khosravi, �ForCES protocol design analysis for 891 protection against DoS attacks� [ICCCN 2004] 893 15.S. Kent, R. Atkinson, �Security Architecture for the Internet 894 Protocol�, RFC 2401 896 11. 897 Acknowledgments 899 Appendix A. TML Service Interface 901 Note that this is just an overview for understanding the protocol 902 initialization/shutdown sequences. It is by no means complete; the 903 complete service interface is being specified in a separate draft. 905 A.1. TML Initialize 907 status tmlInit( 908 in channelType, 909 in initAttributes) 911 Input Parameters: 913 channelType: control versus data channel 914 initAttributes: initialization parameters 916 Output Parameters: 917 none 919 Returns: 920 status: SUCCESS 921 Errors TBD 923 Synopsis: 924 tmlInit() enables establishment of communication channels on the 925 entity that this API is invoked. Optionally specifies attributes if 926 any, for initialization. This call does not however result in the 927 setup of any channels. 929 ForCES Usage Model: 930 In the case of ForCES which follows a client-server model, this API 931 would be invoked on the CE, which functions as the server. It is 932 invoked once for every class of TML channels on a per channel type 933 basis (control channel versus data channel). For example, say for 934 control messaging, the CE communicates with five FEs using TCP TML 935 and with another two FEs, using UDP TML. tmlInit() will need to be 936 invoked twice, once for the TCP TML attributes and once for the UDP 937 TML attributes for the control channel setup with all of the FEs. 938 The same holds true for the data channel setup in the above case. 940 A.2. TML Channel Open 942 status tmlOpen( 943 in elementId, 944 in channelMode, 945 in ctrlChannelAttributes, 946 in dataChannelAttributes, 947 in eventHandlerCallBack) 949 Input Parameters: 950 elementId: Specific CE for which channel needs to be setup 951 channelMode: unicast versus multicast 952 ctrlChannelAttributes: control channel establishment parameters 953 dataChannelAttributes: data channel establishment parameters 954 eventHandlerCallback: Callback function to be invoked on event 955 generation 957 Output Parameters: 958 none 960 Returns: 961 status: SUCCESS 962 Errors TBD 964 Synopsis: 965 tmlOpen() results in one or more communication channels for control 966 and data messaging being established with the specified elementId. 967 It is up to the TML layer implementation whether to setup a single 968 channel for both control and data messaging or distinct channels for 969 each. The channel may be specified as unicast or multicast via 970 channelMode. This call may either trigger the establishment of the 971 channel(s), or if the channel(s) are already established, it only 972 results in a registration for the channel(s). In either case, if 973 successful, status is returned to indicate successful 974 creation/registration of the control and data channels. No 975 descriptors are returned to the PL layer since the TML layer 976 maintains the mapping between the PL provided elementId and the 977 descriptors it allocates. If this call triggers the establishment of 978 the control and data channels, the channels are established using 979 the ctrlChannelAttributes and dataChannelAttributes parameters 980 respectively, specified to the call. Once the channel(s) are setup 981 (or if already setup prior to this call), the caller of this API is 982 also capable of receiving TML events via the specified event 983 handling callback function. If this call is invoked multiple times 984 on a channel that has already been opened and registered, a return 985 status of ALREADY_REGISTERED is returned, with no change to 986 registration. 988 ForCES Usage Model: 989 In the case of ForCES which follows a client-server model, this API 990 would be invoked on the FE by FE PL, which functions as the client. 991 On each FE, it is invoked once for both control and data channels 992 that the FE wishes to setup with the CE. 994 Notes: 995 In the case of TCP TML for the control channel, since there is no 996 inherent support for multicast, regardless of the channelMode 997 specified, the specified channel would be setup as a unicast 998 channel; however, the unicast channel would be able to support 999 pseudo multicast. Hence, TCP TML has no need to set up distinct 1000 channels for unicast and multicast communication; they are both 1001 mapped to the same TCP connection. 1003 In the case of DCCP TML for the data channel, multicast mode is not 1004 being supported. Hence, channelMode would be ignored. 1006 A.3. TML Channel Close 1007 status tmlClose( 1008 in elementId, 1009 in mode) 1011 Input Parameters: 1012 elementId: address of element with which communication channel is 1013 to be terminated 1014 mode: mode of operation for the close � forced versus controlled 1016 Output Parameters: 1017 none 1019 Returns: 1020 status: SUCCESS 1021 Errors TBD 1023 Synopsis: 1024 Tears down/terminates communication channels connecting to the 1025 specified elementId. This API closes both control and data channels 1026 (regardless of whether they are implemented as a single channel or 1027 distinct channels in the TML layer); it is not possible to close 1028 just one of them. No further CE PL � FE PL messaging is possible 1029 after this. If the mode is specified as controlled, current 1030 messages that are pending in the TML layer shall be sent, but no new 1031 messages shall be accepted by the TML layer on this channel. In the 1032 forced mode, messages pending in the TML layer shall be discarded. 1033 Since the channel was terminated, a subsequent tmlOpen() will 1034 trigger establishment of the channel. 1036 ForCES Usage Model: 1037 This API may be invoked by either the CE or the FE. If the FE PL 1038 invokes it, it specifies a CE ID for the elementId. If the CE PL 1039 invokes it, it specifies an FE ID for the elementId. 1041 A.4. TML Channel Write 1043 status tmlWrite( 1044 in elementId, 1045 in msgType, 1046 in msg, 1047 in msgSize, 1048 in timeout, 1049 out bytesWritten) 1051 Input Parameters: 1052 elementId: address of element to be written to; may be a unicast, 1053 multicast or broadcast address 1054 msgType: control versus data message 1055 msg: message to be sent 1056 msgSize: size of message to be sent 1057 timeout: specifies blocking or non-blocking write. Value of -1 1058 implies blocking write (wait forever), value of 0 implies non- 1059 blocking write 1061 Output Parameters: 1062 bytesWritten: number of bytes actually transmitted 1064 Returns: 1065 status: SUCCESS 1066 Errors TBD 1068 Synopsis: 1069 Sends message to the address specified by elementId. If the 1070 specified elementId is associated with a multicast group, the 1071 message will be sent to all members of the group. Similarly, if the 1072 elementId specified is a broadcast address, the message is sent to 1073 all elements associated with the broadcast address. The msgType 1074 parameter is used to specify whether the message is a control or 1075 data type of message. Based on the message type, the TML will send 1076 the message over the appropriate channel. The TML layer uses the 1077 address specified by elementId and the msgType to map to the 1078 appropriate channel to be used for sending the message. The message 1079 is queued in the appropriate queue for transmission. Once this call 1080 returns, the message buffer may be freed. If TML�s message queues 1081 are full, the timeout will be used to determine how long to wait 1082 prior to returning; if the specified timeout expires, and no message 1083 buffer becomes available, the API returns with an error. 1085 ForCES Usage Model: 1086 This API may be invoked by either the FE PL or the CE PL. If the FE 1087 PL invokes it, it specifies a CE ID for the elementId. If the CE PL 1088 invokes it, it specifies an (unicast/multicast/broadcast) FE ID for 1089 the elementId. 1090 In the case of TCP TML since there is a single channel used for 1091 unicast, multicast and broadcast messaging, the same channel is used 1092 for sending messages regardless of the address specified. In other 1093 cases where there are distinct channels for unicast versus 1094 multicast, the channel to be written to will differ based on the 1095 address specified. 1097 A.5. TML Channel Read 1099 status tmlRead( 1100 in elementId, 1101 in msgType, 1102 in msgBuf, 1103 in timeout, 1104 out bytesRead) 1106 Input Parameters: 1107 elementId: address of element to be read from; may be a unicast, 1108 multicast or broadcast address 1109 msgType: control versus data message 1110 msgBuf: buffer into which message is to be read 1111 timeout: specifies blocking or non-blocking read. Value of -1 1112 implies blocking read (wait forever), value of 0 implies non- 1113 blocking read 1115 Output Parameters: 1116 bytesRead: number of bytes actually read 1118 Returns: 1119 status: SUCCESS 1120 Errors TBD 1122 Synopsis: 1123 Reads message from the specified address. The msgType parameter is 1124 used to specify whether the message to be read is a control or data 1125 type of message. The TML layer uses the address specified by 1126 elementId and the msgType to map to the appropriate channel to be 1127 used for reading the message. Once the message is copied into 1128 msgBuf specified by the call, the TML message buffer may be freed. 1129 If TML�s message queues are empty (no message is available), the 1130 timeout will be used to determine how long to wait prior to 1131 returning; if the specified timeout expires, and no message becomes 1132 available, the API returns with an error. 1133 If a non-blocking read is executed, the caller of the API is 1134 notified via an upcall when a message becomes available. 1136 ForCES Usage Model: 1137 This API may be invoked by either the CE or the FE. If the FE PL 1138 invokes it, it specifies a CE ID for the elementId. If the CE PL 1139 invokes it, it specifies an (unicast/multicast/broadcast) FE ID for 1140 the elementId. 1142 In the case of TCP TML since there is a single channel used for 1143 unicast, multicast and broadcast messaging, the same channel is used 1144 for reading messages regardless of the address specified. In other 1145 cases where there are distinct channels for unicast versus 1146 multicast, the channel to be read from will differ based on the 1147 address specified. 1149 A.6. TML Multicast Group Join 1151 status tmlMulticastGroupJoin( 1152 in groupId, 1153 in groupAttributes) 1155 Input Parameters: 1156 groupId: address of multicast group to join 1157 groupAttributes: attributes associated with the multicast group to 1158 be joined 1160 Output Parameters: 1161 none 1163 Returns: 1164 status: SUCCESS 1165 Errors TBD 1167 Synopsis: 1168 Joins the multicast group specified by groupId as leaf node in the 1169 group. Once a member of this group, the entity calling this API will 1170 be capable of receiving messages addressed to this multicast group. 1171 The TML layer on each end (CE/FE) maintains the mapping between the 1172 PL layer multicast address and the descriptors. The TML layer on 1173 the element which is the root of the multicast updates the set of 1174 elements that are members of the group specified by groupId. 1176 ForCES Usage Model: 1177 This API would be invoked on both the CE and the FE. Initially, the 1178 intent is to only support FE multicast. In such a case. on the FE 1179 the API is invoked once the PL layer on the FE receives a request 1180 from the PL layer on the CE to join a specified multicast group. On 1181 the CE it is invoked after the FE has successfully joined the 1182 multicast group. 1184 A.7. TML Multicast Group Leave 1186 status tmlMulticastGroupLeave( 1187 in groupId) 1189 Input Parameters: 1190 groupId: address of multicast group to leave 1192 Output Parameters: 1193 none 1195 Returns: 1197 status: SUCCESS 1198 Errors TBD 1200 Synopsis: 1201 Leaves the multicast group specified by groupId it had previously 1202 joined. Once an entity is not a member of the multicast group, it is 1203 no longer capable of receiving messages addressed to group. The 1204 TML layer on each end (CE/FE) updates the mapping between the PL 1205 layer multicast address and the descriptors. The TML layer on the 1206 element which is the root of the multicast updates the set of 1207 elements that are members of the group specified by groupId. 1209 ForCES Usage Model: 1210 This API would be invoked on both the CE and the FE. Initially, the 1211 intent is to only support FE multicast. In such a case, on the FE 1212 the API is invoked once the PL layer on the FE receives a request 1213 from the PL layer on the CE to leave a specified multicast group. On 1214 the CE it is invoked after the FE has successfully left the 1215 multicast group. 1217 Authors' Addresses 1219 Hormuzd Khosravi 1220 Intel 1221 2111 NE 25th Avenue 1222 Hillsboro, OR 97124 1223 Phone: 1-503-264-0334 1224 Email: hormuzd.m.khosravi@intel.com 1226 Furquan Ansari 1227 101 Crawfords Corner Road 1228 Holmdel, NJ 07733 1229 USA 1230 Phone: +1 732-949-5249 1231 Email: furquan@lucent.com 1233 Jon Maloy 1234 Ericsson Research Canada 1235 8400 Boul Decarie 1236 Ville Mont-Royal, Quebec H4P 2N2 1237 Canada 1238 Phone: 1-514-345-7900 1239 Email: jon.maloy@ericsson.com 1241 Shuchi Chawla 1242 Intel 1243 2111 NE 25th Avenue 1244 Hillsboro, OR 97124 1245 Phone: 1-503-712-4539 1246 Email: shuchi.chawla@intel.com 1248 Copyright Statement 1250 Copyright (C) The Internet Society (2006). This document is subject 1251 to the rights, licenses and restrictions contained in BCP 78, and 1252 except as set forth therein, the authors retain all their rights. 1254 This document and the information contained herein are provided on 1255 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1256 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1257 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1258 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1259 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1260 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.