idnits 2.17.1 draft-khosravi-forces-tcptml-01.txt: -(274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(698): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(928): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1038): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1076): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1098): 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 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1159. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 32 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 24 longer pages, the longest (page 21) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 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 65 instances of too long lines in the document, the longest one being 160 characters in excess of 72. ** The abstract seems to contain references ([3], [7]), 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 1024: '... the CEs and FEs MUST be established b...' RFC 2119 keyword, line 1033: '...points that implement TLS MUST perform...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 135 has weird spacing: '... define both ...' == Line 140 has weird spacing: '...ultiple trans...' == Line 142 has weird spacing: '... will take ...' == Line 510 has weird spacing: '... in chann...' == Line 511 has weird spacing: '... in initA...' == (16 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 (February 2005) is 7009 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) -- Looks like a reference, but probably isn't: '2' on line 42 -- Looks like a reference, but probably isn't: '3' on line 304 -- Looks like a reference, but probably isn't: '7' on line 305 -- Looks like a reference, but probably isn't: '5' on line 106 == Missing Reference: 'RFC3746' is mentioned on line 111, but not defined -- Looks like a reference, but probably isn't: '4' on line 149 == Missing Reference: 'Reqs' is mentioned on line 313, but not defined -- Looks like a reference, but probably isn't: '11' on line 321 -- Looks like a reference, but probably isn't: '8' on line 1030 == Missing Reference: 'ICCCN 2004' is mentioned on line 1112, but not defined == Unused Reference: 'SoftCOM 2004' is defined on line 1109, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'SoftCOM 2004' Summary: 15 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Hormuzd Khosravi 2 Internet Draft Shuchi Chawla 3 Document: draft-khosravi-forces-tcptml-01.txt Intel Corp. 4 Expires: August 2005 Furquan Ansari 5 Working Group: ForCES Lucent Tech. 6 Jon Maloy 7 Ericsson 9 February 2005 11 TCP/IP based TML (Transport Mapping Layer) for ForCES protocol 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance 18 with RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as ``work in 29 progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Conventions used in this document 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 41 this document are to be interpreted as described in [2]. 43 Abstract 45 This document defines the TCP/IP based TML (Transport Mapping Layer) 46 for the ForCES protocol. It explains the rationale for choosing the 47 transport protocols and also describes how this TML addresses all 48 the requirements described in the Forces [3] requirements and ForCES 49 protocol [7] document. 51 Table of Contents 53 1. Definitions.....................................................3 54 2. Introduction....................................................3 55 3. Protocol Framework Overview.....................................4 56 3.1.1. The PL layer................................................5 57 3.1.2. The TML layer...............................................5 58 4. TCP/IP TML Overview.............................................5 59 4.1. Rationale for using TCP/IP....................................6 60 4.2. Separate Control and Data channels............................6 61 4.3. Reliability...................................................7 62 4.4. Congestion Control............................................8 63 4.5. Security......................................................8 64 4.6. Addressing....................................................8 65 4.7. Prioritization................................................8 66 4.8. HA Decisions..................................................8 67 4.9. Encapsulations Used...........................................8 68 5. TML Messaging...................................................8 69 5.1. TML Message Header............................................9 70 5.1.1. Version (version)...........................................9 71 5.1.2. Upper Layer Protocol Flag (f)...............................9 72 5.1.3. Message Type (msgType)......................................9 73 5.1.4. TML Message Length (tmlMsgLength)...........................9 74 5.1.5. TML Message Body...........................................10 75 5.2. TML Messages.................................................10 76 5.2.1. Channel Close..............................................10 77 5.2.2. Heartbeat..................................................10 78 5.2.3. Multicast Group Join Request...............................10 79 5.2.4. Multicast Group Join Response..............................10 80 5.2.5. Multicast Group Leave Request..............................11 81 5.2.6. Multicast Group Leave Response.............................11 82 6. TML Interface to Upper layer Protocol..........................11 83 6.1. TML API......................................................11 84 6.1.1. TML Initialize.............................................11 85 6.1.2. TML Channel Open...........................................12 86 6.1.3. TML Channel Close..........................................13 87 6.1.4. TML Channel Write..........................................14 88 6.1.5. TML Channel Read...........................................15 89 6.1.6. TML Multicast Group Join...................................16 90 6.1.7. TML Multicast Group Leave..................................16 91 6.2. Protocol Initialization and Shutdown Model...................17 92 6.2.1. Protocol Initialization....................................17 93 6.2.2. Protocol Shutdown..........................................18 94 6.3. Multicast Model..............................................20 95 7. Security Considerations........................................22 96 7.1. TLS Usage for this TML.......................................22 97 8. IANA Considerations............................................23 98 9. References.....................................................23 99 9.1. Normative References.........................................23 100 9.2. Informative References.......................................23 101 10. Acknowledgments...............................................24 102 11. Authors' Addresses............................................24 104 1. Definitions 106 The following definitions are taken from [3], [5] 108 ForCES Protocol - While there may be multiple protocols used within 109 the overall ForCES architecture, the term "ForCES protocol" refers 110 only to the protocol used at the Fp reference point in the ForCES 111 Framework in RFC3746 [RFC3746]. This protocol does not apply to 112 CE-to-CE communication, FE-to-FE communication, or to communication 113 between FE and CE managers. Basically, the ForCES protocol works in 114 a master-slave mode in which FEs are slaves and CEs are masters. 116 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 117 architecture that defines the ForCES protocol messages, the protocol 118 state transfer scheme, as well as the ForCES protocol architecture 119 itself (including requirements of ForCES TML (see below)). 120 Specifications of ForCES PL are defined by this document. 122 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 123 ForCES protocol architecture that specifically addresses the 124 protocol message transportation issues, such as how the protocol 125 messages are mapped to different transport media (like TCP, IP, ATM, 126 Ethernet, etc), and how to achieve and implement reliability, 127 multicast, ordering, etc. This document defines a TCP/IP based 128 ForCES TML. 130 2. Introduction 132 The ForCES (Forwarding and Control Element Separation) working group 133 in the IETF is defining the architecture and protocol for separation 134 of control and forwarding elements in network elements such as 135 routers. [3], [4] define both architectural and protocol 136 requirements for the communication between CE and FE. The ForCES 137 protocol layer [7] describes the protocol specification. It is 138 envisioned that the ForCES protocol would be independent of the 139 interconnect technology between the CE and FE and can run over 140 multiple transport technologies and protocol. Thus a Transport 141 Mapping Layer (TML) has been defined in the protocol framework that 142 will take care of mapping the protocol messages to specific 143 transports. This document defines the TCP/IP based TML for the 144 ForCES protocol layer. It also addresses all the requirements for 145 the TML including security, reliability, etc. 147 3. Protocol Framework Overview 149 The reader is referred to the Framework document [4], and in 150 particular sections 3 and 4, for architectural overview and where 151 and how the ForCES protocol fits in. There may be some content 152 overlap between the ForCES protocol draft [7] and this section in 153 order to provide clarity. 155 The ForCES protocol constitutes two pieces: the PL and TML layer. 156 This is depicted in Figure 1 below. 158 +------------------------------------------------ 159 | CE PL layer | 160 +------------------------------------------------ 161 | CE TML layer | 162 +------------------------------------------------ 163 ^ 164 | 165 ForCES | (i.e. Forces data + control 166 PL | packets ) 167 messages | 168 over | 169 specific | 170 TML | 171 encaps | 172 and | 173 transport | 174 | 175 v 176 +------------------------------------------------ 177 | FE TML layer | 178 +------------------------------------------------ 179 | FE PL layer | 180 +------------------------------------------------ 182 Figure 1: ForCES Interface 184 The PL layer is in fact the ForCES protocol. Its semantics and 185 message layout are defined in [7]. The TML Layer is necessary to 186 connect two ForCES PL layers as shown in Figure 1 above. 188 Both the PL and TML layers are standardized by the IETF. While only 189 one PL layer is defined, different TMLs are expected to be 190 standardized. To interoperate the TML layer at the CE and FE are 191 expected to be of the same definition. 193 On transmit, the PL layer delivers its messages to the TML layer. 194 The TML layer delivers the message to the destination TML layer(s). 195 On reception, the TML delivers the message to its destination PL 196 layer(s). 198 3.1.1.The PL layer 200 The PL is common to all implementations of ForCES and is 201 standardized by the IETF [7]. The PL layer is responsible for 202 associating an FE or CE to an NE. It is also responsible for 203 tearing down such associations. An FE uses the PL layer to throw 204 various subscribed-to events to the CE PL layer as well as respond 205 to various status requests issued from the CE PL. The CE configures 206 both the FE and associated LFBs attributes using the PL layer. In 207 addition the CE may send various requests to the FE to activate or 208 deactivate it, reconfigure it�s HA parameterization, subscribe to 209 specific events etc. 211 3.1.2.The TML layer 213 The TML layer is essentially responsible for transport of the PL 214 layer messages. The TML is where the issues of how to achieve 215 transport level reliability, congestion control, multicast, 216 ordering, etc. are handled. It is expected more than one TML will 217 be standardized. The different TMLs each could implement things 218 differently based on capabilities of underlying media and transport. 219 However, since each TML is standardized, interoperability is 220 guaranteed as long as both endpoints support the same TML. All 221 ForCES Protocol Layer implementations should be portable across all 222 TMLs, because all TMLs have the same top edge semantics. 224 4. TCP/IP TML Overview 226 The TCP/IP TML consists of two TCP connections between the CE and FE 227 over which the protocol messages are exchanged. One of the 228 connections is called the control channel, over which control 229 messages are exchanged, the other is called data channel over which 230 external protocol packets, such as routing packets will be 231 exchanged. The TCP connections will use unique server port numbers 232 for each of the channels. In addition to this, this TML will provide 233 mechanisms to prioritize the messages over the different channels. 235 Some of the rationale for choosing this transport mechanism as well 236 as explanation of how it meets the TML requirements is explained 237 below. 239 4.1.Rationale for using TCP/IP 241 TCP meets all the reliability requirements (no losses, no data 242 corruption, no re-ordering of data) for the ForCES protocol/TML and 243 also provides congestion control mechanism, which is important to 244 meet the scalability requirement. In addition, it helps with 245 interoperability since TCP is a well-understood, widely deployed 246 transport protocol. Using TCP also enables this TML and the protocol 247 to work seamlessly in single hop and multihop scenarios. 249 4.2.Separate Control and Data channels 251 The ForCES NEs are subject to Denial of Service (DoS) attacks 252 [Requirements Section 7 #15]. A malicious system in the network can 253 flood a ForCES NE with bogus control packets such as spurious RIP or 254 OSPF packets in an attempt to disrupt the operation of and the 255 communication between the CEs and FEs. In order to protect against 256 this situation, the TML uses separate control and data channels for 257 communication between the CEs and FEs. Figure 2 below illustrates 258 the different communication channels between the CEs and the FEs; 259 the communication channels for support of High Availability with 260 redundant CEs are also included. 262 ACTIVE CE STANDBY CE 263 +-------------------+ +-------------------+ 264 | CE: PL | | CE: PL | 265 +-------------------+ +-------------------+ 266 | CE: TML | | CE: TML | 267 +-------------------+ +-------------------+ 268 | CE: TCP | | CE: TCP | 269 +-------------------+ +-------------------+ 270 | | | | | | | | | | 271 | . | . | . | . | . 272 | | | | | | | | | | 273 | . | . | . | . | . 274 | | | | | | Cc1� Cd1� Cc2� Cd2�Ccn� Cdn� 275 | . | . | . 276 +-Cc1-----+ | | | | +-.-.-.-.-.Cdn.-+ 277 | +-Cd1-.-.+ | . +--------Ccn---+ | 278 | | | | | . 279 | . +Cc2+ . | | 280 | | | +Cd2+ | . 281 | . | | | | 283 +-----------+ +-----------+ +-----------+ 284 | FE: TCP | | FE: TCP | . . . | FE: TCP | 285 +-----------+ +-----------+ +-----------+ 286 | FE: TML | | FE: TML | | FE: TML | 287 +-----------+ +-----------+ +-----------+ 288 | FE: PL | | FE: PL | | FE: PL | 289 +-----------+ +-----------+ +-----------+ 290 FE1 FE2 FEn 291 \-------------V------------/ 292 FE 1+1 Redundancy 294 Legend: 295 ---- Cc# : Unicast Control Channel between Active CE and FE# 296 -.-. Cd# : Unicast Data Channel between Active CE and FE# 298 ---- Cc#�: Unicast Control Channel between Standby CE and FE# 299 -.-. Cd#�: Unicast Data Channel between Standby CE and FE# 301 Figure 2: CE-FE Communication Channels 303 The data channel carries the control protocol packets such as RIP, 304 OSPF messages as outlined in Requirements [3] Section 7 #10, which 305 are carried in ForCES Packet Redirect messages [7], between the CEs 306 and FEs. All the other ForCES messages, which are used for 307 configuration/capability exchanges, event notification, etc, are 308 carried over the control channel. The data channel is set up only 309 after the control channel is set up. By default, the data channel is 310 established on the CE control channel port number +1. 312 The reliability requirements for the data channel messages are 313 different from that of the control messages [Reqs] i.e. they don�t 314 require strict reliability in terms of retransmission, etc. However 315 congestion control is important for the data channel because in case 316 of DoS attacks, if an unreliable transport such as UDP is used for 317 the data traffic, it can more easily overflow the physical 318 connection, overwhelming the control traffic with congestion. Thus 319 we need a transport protocol that provides congestion control but 320 does not necessarily provide full reliability. Datagram Congestion 321 Control Protocol (DCCP) [11], which is currently being defined, is a 322 transport protocol that exactly meets this requirement. However 323 since it is currently not an IETF standard RFC, and the authors are 324 unaware of any existing implementations, this TML uses TCP as 325 transport protocol for the data channel (for IP interconnect). TCP 326 provides the congestion control mechanism required for the data 327 channel and its wide deployment eases interoperability. 329 4.3.Reliability 330 TCP provides the reliability (no losses, no data corruption, no re- 331 ordering of data) required for ForCES protocol control messages. 333 4.4.Congestion Control 335 TCP provides congestion control needed to satisfy this requirement. 337 4.5.Security 339 This TML uses TLS [8] to provide security in insecure environments. 340 Please see section 7 on security considerations for more details. 342 4.6.Addressing 344 This TML uses addressing provided by IP layer. For unicast 345 addressing/delivery, it uses the TCP connection between the CE and 346 FE. For multicast/broadcast addressing/delivery, this TML uses 347 multiple TCP connections between the CE and FEs. 349 4.7.Prioritization 351 This TML provides prioritization of messages sent over control 352 channel as compared to the data channel. This has also been found to 353 be useful in face of DoS attacks on the protocol. The details of 354 this are TBD. 356 4.8.HA Decisions 358 The TML layer supports heartbeat messages between peer TML layers to 359 indicate liveness of the entity generating it. The frequency of the 360 heartbeat message may be specified at protocol initialization time. 362 4.9.Encapsulations Used 364 TML adds its own header on all ForCES protocol messages that it 365 receives, and additionally on messages it generates. The ForCES 366 protocol and TML messages are further encapsulated with a TCP/IP 367 header. The format of the TML header is specified in Section 5. 369 5. TML Messaging 371 TML adds on a TML header to all messages that it either receives 372 from the PL layer or those messages that it generates. The TML 373 header is followed by the message body. The message body may 374 comprise a PL message or it may be a message generated by the TML 375 layer for communicating with its peer. A flag in the TML header 376 specifies whether the message is associated with the PL layer. The 377 next section details the TML header. 379 5.1.TML Message Header 381 Figure 3 below shows the format of the TCP TML message header. 382 NOTE: The header may undergo some modifications in the next revision 383 of this draft. 385 0 1 2 3 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |version|reserved |f| msgType | tmlMsgLength | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | TBD: message body | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 3: TCP TML Message Header Format 394 5.1.1.Version (version) 396 The version field (4 bits) specifies the version of the TML layer 397 protocol supported by the implementation. An entity implementing 398 the TML layer protocol should be backward compatible with previous 399 versions of the protocol. 401 5.1.2.Upper Layer Protocol Flag (f) 403 The upper layer protocol flag (1 bit) specifies if the TML layer is 404 carrying a message sent by the PL Layer. If the protocol flag is 405 set, the message body comprises of a PL message which is not 406 interpreted by the peer TML layer; the rest of the TML header and 407 message is ignored by the peer TML layer. If the protocol flag is 408 not set, the message body carries a TML message; hence, the rest of 409 the TML header needs to be read by the peer TML layer and the 410 message body appropriately processed. 412 5.1.3.Message Type (msgType) 414 The message type (6 bits) field is applicable only if the protocol 415 flag field is not set. It specifies the TML message being sent 416 between peer TML layers. 418 5.1.4.TML Message Length (tmlMsgLength) 420 The TML message length field is applicable only if the protocol flag 421 field is not set. It specifies the length of the TML message in 422 octets inclusive of the TML header. 424 5.1.5.TML Message Body 426 Format of this is TBD. 428 5.2.TML Messages 430 5.2.1.Channel Close 432 The channel close message is generated by the TML layer in response 433 to a request to close a specified channel. This message is sent to 434 the peer TML layer to notify it of the closure. This provides 435 information to the peer TML layer so it can either close its end of 436 the channel also or drop any messages received by the upper layer 437 protocol. 439 ForCES protocol usage: This message may be sent from either the CE 440 or the FE TML layer depending on which entity initiated the close. 442 5.2.2.Heartbeat 444 A heartbeat message is exchanged between peer TML layers to 445 communicate liveness of the entity generating the message. 447 ForCES protocol usage: This message may be sent from either the CE 448 to an FE or vice-versa. 450 5.2.3.Multicast Group Join Request 452 The multicast group join request message is triggered by a request 453 from the PL layer to join a specific multicast group. The peer TML 454 layer on receiving this request creates the specified multicast 455 group if it didn�t previously exist. It updates the membership of 456 the group to include the entity requesting the join. 458 ForCES protocol usage: Since only FEs may be the leaves in a 459 multicast group, this message is sent by the FE TML to the CE TML, 460 due to a join request from the FE PL. 462 5.2.4.Multicast Group Join Response 464 The multicast group join response message is generated by the TML 465 Layer in response to a join request message. 467 ForCES protocol usage: If only FEs may be the leaves in a multicast 468 group, this message is generated by the CE TML and sent to the FE 469 TML, in response to the join request message received from the FE 470 TML. 472 5.2.5.Multicast Group Leave Request 474 The multicast group leave request message is triggered by a request 475 from the PL layer to leave a specific multicast group. The peer TML 476 layer on receiving this request removes the specified multicast 477 group if the entity requesting to leave is the only member of the 478 group. Else, it updates the membership of the group to exclude the 479 entity requesting the leave. 481 ForCES protocol usage: If only FEs may be the leaves in a multicast 482 group, this message is sent by the FE TML to the CE TML, due to a 483 leave request from the FE PL. 485 5.2.6.Multicast Group Leave Response 487 The multicast group leave response message is generated by the TML 488 Layer in response to a leave request message. 490 ForCES protocol usage: If only FEs may be the leaves in a multicast 491 group, this message is generated by the CE TML and sent to the FE 492 TML, in response to the leave request message received from the FE 493 TML. 495 6. TML Interface to Upper layer Protocol 497 ForCES TML interfaces with an upper layer protocol, the PL Layer and 498 a lower layer protocol, TCP (in the case of TCP TML). This section 499 defines the interface to the upper layer protocol. This interface 500 should be used only as a guideline in implementing the API. 501 Additionally, although the current interface is defined mainly as a 502 synchronous interface, the interface may be implemented to be 503 asynchronous if desired. 505 6.1.TML API 507 6.1.1.TML Initialize 509 status tmlInit( 510 in channelType, 511 in initAttributes) 513 Input Parameters: 514 channelType: control versus data channel 515 initAttributes: initialization parameters 517 Output Parameters: 518 none 520 Returns: 521 status: SUCCESS 522 Errors TBD 524 Synopsis: 525 tmlInit() enables establishment of communication channels on the 526 entity that this API is invoked. Optionally specifies attributes if 527 any, for initialization. This call does not however result in the 528 setup of any channels. 530 ForCES Usage Model: 531 In the case of ForCES which follows a client-server model, this API 532 would be invoked on the CE, which functions as the server. It is 533 invoked once for every class of TML channels on a per channel type 534 basis (control channel versus data channel). For example, say for 535 control messaging, the CE communicates with five FEs using TCP TML 536 and with another two FEs, using UDP TML. tmlInit() will need to be 537 invoked twice, once for the TCP TML attributes and once for the UDP 538 TML attributes for the control channel setup with all of the FEs. 539 The same holds true for the data channel setup in the above case. 541 6.1.2.TML Channel Open 543 status tmlOpen( 544 in channelType, 545 in elementId, 546 in channelMode, 547 in channelAttributes, 548 in eventHandlerCallBack, 549 out channelDescriptor) 551 Input Parameters: 552 channelType: control channel or data channel 553 elementId: Specific CE for which channel needs to be setup 554 channelMode: unicast versus multicast 555 channelAttributes: channel establishment parameters 556 eventHandlerCallback: Callback function to be invoked on event 557 generation 559 Output Parameters: 560 channelDescriptor: handle to communication channel 562 Returns: 563 status: SUCCESS 564 Errors TBD 566 Synopsis: 567 tmlOpen() results in a communication channel of type channelType 568 (control versus data), being established with the specified 569 elementId. The channel may be specified as unicast or multicast via 570 channelMode. This call may either trigger the establishment of the 571 channel, or if the channel is already established, it only results 572 in a registration for that channel. In either case, if successful, 573 a handle to the open channel is returned via a channelDescriptor. 574 If this call triggers the establishment of the channel, the channel 575 is established using the channelAttributes parameter specified to 576 the call. Once the channel is setup (or if already setup prior to 577 this call), the caller of this API is also capable of receiving TML 578 events via the specified event handling callback function. If this 579 call is invoked multiple times on a channel that has already been 580 opened and registered, a return status of ALREADY_REGISTERED is 581 returned, with no change to registration. 583 ForCES Usage Model: 584 In the case of ForCES which follows a client-server model, this API 585 would be invoked on the FE by FE PL, which functions as the client. 586 On each FE, it is invoked once per channel that the FE wishes to 587 setup with the CE. 589 Notes: 590 In the case of TCP TML, since there is no inherent support for 591 multicast, regardless of the channelMode specified, the specified 592 channel would be setup as a unicast channel; however, the unicast 593 channel would be able to support pseudo multicast. Hence, there is 594 no need to set up a distinct channel for unicast and a distinct 595 channel for multicast in the case of TCP TML (as may be the case for 596 UDP TML). 598 6.1.3. TML Channel Close 600 status tmlClose( 601 in channelDescriptor 602 in mode) 604 Input Parameters: 605 channelDescriptor: handle to communication channel to be 606 terminated 607 mode: mode of operation for the close � forced versus controlled 609 Output Parameters: 610 none 612 Returns: 613 status: SUCCESS 614 Errors TBD 616 Synopsis: 617 Tears down/terminates specified communication channel. No further 618 CE PL � FE PL messaging is possible after this. If the mode is 619 specified as controlled, current messages that are pending in the 620 TML layer shall be sent, but no new messages shall be accepted by 621 the TML layer on this channel. In the forced model, messages 622 pending in the TML layer shall be discarded. Since the channel was 623 terminated, a subsequent tmlOpen() will trigger establishment of the 624 channel. 626 ForCES Usage Model: 627 This API may be invoked by either the CE or the FE. If the FE PL 628 invokes it, the FE TML sends a message to the CE TML informing it 629 that the channel has been shutdown, which results in an upcall to 630 the CE PL. This will result in the CE PL also shutting down its end 631 of the channel. 633 6.1.4.TML Channel Write 635 status tmlWrite( 636 in channelDescriptor, 637 in msg, 638 in msgSize, 639 in timeout, 640 out bytesWritten) 642 Input Parameters: 643 channelDescriptor: handle to communication channel to be written 644 to 645 msg: message to be sent 646 msgSize: size of message to be sent 647 timeout: specifies blocking or non-blocking write. Value of -1 648 implies blocking write (wait forever), value of 0 implies non- 649 blocking write 651 Output Parameters: 652 bytesWritten: number of bytes actually transmitted 654 Returns: 655 status: SUCCESS 656 Errors TBD 658 Synopsis: 660 Sends message over the specified channel. If the specified 661 channelDescriptor is associated with a multicast group, the message 662 will be sent to all members of the group. This does not imply that 663 the message has actually been transmitted. The message is queued in 664 the appropriate queue for transmission. Once this call returns, the 665 message buffer may be freed. If TML�s message queues are full, the 666 timeout will be used to determine how long to wait prior to 667 returning; if the specified timeout expires, and no message buffer 668 becomes available, the API returns with an error. 670 ForCES Usage Model: 671 This API may be invoked by either the FE PL or the CE PL. 673 6.1.5.TML Channel Read 675 status tmlRead( 676 in channelDescriptor, 677 in msgBuf, 678 in timeout, 679 out bytesRead) 681 Input Parameters: 682 channelDescriptor: handle to communication channel to be read from 683 msgBuf: buffer into which message is to be read 684 timeout: specifies blocking or non-blocking read. Value of -1 685 implies blocking read (wait forever), value of 0 implies non- 686 blocking read 688 Output Parameters: 689 bytesRead: number of bytes actually read 691 Returns: 692 status: SUCCESS 693 Errors TBD 695 Synopsis: 696 Reads message on the specified channel. Once the message is copied 697 into msgBuf specified by the call, the TML message buffer may be 698 freed. If TML�s message queues are empty (no message is available), 699 the timeout will be used to determine how long to wait prior to 700 returning; if the specified timeout expires, and no message becomes 701 available, the API returns with an error. 702 If a non-blocking read is executed, the caller of the API is 703 notified via an upcall when a message becomes available. 704 TBD: If the channelDescriptor specified is associated with a 705 multicast group, it should be considered invalid since multicast is 706 only supported on a write; a read is always associated with reading 707 from a single channel. 709 6.1.6.TML Multicast Group Join 711 status tmlMulticastGroupJoin( 712 in groupAttributes) 714 Input Parameters: 715 groupAttributes: Attributes associated with the multicast group to 716 be joined 718 Output Parameters: 719 none 721 Returns: 722 status: SUCCESS 723 Errors TBD 725 Synopsis: 726 Joins the specified multicast group as leaf node in the group. If 727 this is the first join request being received for this group, it 728 results in the creation of the group and the allocation of a 729 groupDescriptor (which is equivalent to a channelDescriptor). Once a 730 member of this group, the entity calling this API will be capable of 731 receiving messages addressed to this multicast group. 733 ForCES Usage Model: 734 If the intent is that only FEs can be members of a multicast group 735 and only a CE can be the source of a multicast, this API would be 736 invoked on the FE that wishes to join a multicast group. 738 6.1.7.TML Multicast Group Leave 740 status tmlMulticastGroupLeave( 741 in groupAttributes) 743 Input Parameters: 744 groupAttributes: Attributes associated with the multicast group to 745 leave 747 Output Parameters: 748 none 750 Returns: 751 status: SUCCESS 752 Errors TBD 754 Synopsis: 755 Leaves the specified multicast group it had previously joined. Once 756 an entity is not a member of the multicast group, it is no longer 757 capable of receiving messages addressed to group. If this leave 758 request is associated with the only member of the group, the 759 multicast group is removed, and its associated groupDescriptor 760 invalidated. 762 ForCES Usage Model: 763 If the intention is that only FEs can be members of a multicast 764 group and only a CE can be the source of a multicast, this API would 765 be invoked on the FE that wishes to leave a group it had previously 766 joined. 768 6.2.Protocol Initialization and Shutdown Model 770 In order for the peer PL Layers to communicate, the control and data 771 channels must be setup. This section defines a model for the setup 772 of the channels, using the TML interface defined above. In this 773 model, the peer TML Layers may establish the control and data 774 channels between the FE and the CE without the involvement of the PL 775 Layers, or if desired, the PL Layer may trigger the setup of the 776 channels; this is left as an implementation decision. Both modes 777 may also be supported within an implementation. 779 6.2.1.Protocol Initialization 781 The control channel must be established between the FE TML and the 782 CE TML for establishment of association to proceed. This channel 783 will be used for messages related to the association setup and 784 capability query. The data channel must be established no later 785 than the response from the FE to the CE Topology query message. 787 Figure 4 illustrates the initialization model where the PL layer via 788 an interface provided by the TML Layer, triggers the setup of the 789 control and data channels. 791 FE PL FE TML CE TML CE PL 792 | | | | \ 793 / | | | tmlInit(Cc) | | 794 FE | | | |<--------------| > CE Init/ 795 Init/ < | | | tmlInit(Cd) | | Bootup 796 Bootup | | | |<--------------| / 797 \ | | | | 798 | tmlOpen(Cc) | | | 799 |-------------->| | | \ 800 | |TCP CtrlChan(Cc) Setup | | | 801 | |~~~~~~~~~~~~~~~~~~~~~~>| | | Setup control 802 | |CtrlChann(Cc) Setup Rsp| | > channel if not 803 | |<~~~~~~~~~~~~~~~~~~~~~~| | | already 804 | <-- CcDes | | | | setup 805 |tmlEvent(CcUp) | |tmlEvent(CcUp) | / 806 |<--.--.--.--.--| |--.--.--.--.-->| 807 | | | CcDes | 808 | tmlOpen(Cd) | | | 809 |-------------->| | | \ 810 | |TCP DataChann(Cd) Setup| | | Setup data 811 | |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not 812 | |DataChann(Cd) Setup Rsp| | > channel if not 813 | |<~~~~~~~~~~~~~~~~~~~~~~| | | already 814 | <-- CdDes | | | | setup 815 |tmlEvent(CdUp) | |tmlEvent(CdUp) | / 816 |<--.--.--.--.--| |--.--.--.--.-->| 817 | | | CdDes | 818 | | Asso Setup Req | | 819 |---------------|-----------------------|-------------->| 820 | | Asso Setup Rsp | | 821 |<--------------|-----------------------|---------------| 822 | | | | 823 | | Capability Query | | 824 |<--------------|-----------------------|---------------| 825 | | Capability Query Rsp | | 826 |---------------|-----------------------|-------------->| 827 | | | | 828 | | Topology Query | | 829 |<--------------|-----------------------|---------------| 830 | | Topology Query Rsp | | 831 |---------------|-----------------------|-------------->| 832 | | | | 833 | |STEADY STATE OPERATION | | 834 |<--------------|-----------------------|-------------->| 835 | | | | 837 Legend: 838 PL --------> PL : Protocol layer messaging 839 PL --------> TML: TML API 840 TML ========> TML: Messaging between TML Layers 841 TML --.--.--> PL : Events/Notifications/Upcalls 842 TML ~~~~~~~~> TML: Internal protocol communication 844 Figure 4: Protocol Initialization (Channel Setup) 846 6.2.2.Protocol Shutdown 848 The control channel teardown must occur only after the association 849 teardown has occurred. The data channel teardown may occur no earlier 850 than the association teardown. 852 The PL Layer may completely shutdown a channel via invocation of the 853 tmlClose() API. When the PL layer shuts down a channel, the channel is 854 torn down; hence ForCES messaging between the CE and FE is no longer 855 possible over that channel. A subsequent tmlOpen() triggers 856 establishment of the channel. This scenario is illustrated in Figure 857 5. 859 FE PL FE TML CE TML CE PL 860 | | | | 861 | |STEADY STATE OPERATION | | 862 |<--------------|-----------------------|-------------->| 863 | | Config Request | | 864 |<--------------|-----------------------|---------------| 865 | | Config Response | | 866 |---------------|-----------------------|-------------->| 867 | | | | 868 | | Association Teardown | | 869 |<--------------|-----------------------|---------------| 870 | | | | 871 | | | | 872 |tmlClose(CdDes)| | | \ 873 |-------------->| | | | Data Channel 874 | |DataChan(Cd) Close | | | teardown; it no 875 | |======================>| | > longer exists. 876 |<-- Cd Close OK| |tmlCloseUpcall | | PL Layer can no 877 | | |--.--.--.--.-->| | longer use Cd; 878 | | | | | TML msging also 879 | | | | / not possible. 880 | | | | 881 |tmlClose(CcDes)| | | \ 882 |-------------->| | | | Control Channel 883 | |CtrlChan(Cc) Close | | | teardown; it no 884 | |======================>| | > longer exists. 885 |<-- Cc Close OK| |tmlCloseUpcall | | PL Layer can no 886 | | |--.--.--.--.-->| | longer use Cc; 887 | | | | | TML msging also 888 | | | | / not possible. 889 ~ ~ ~ ~ 890 ~ ~ ~ ~ 891 | | | | 892 | tmlOpen(Cc) | | | \ 893 |-------------->| | | | Subsequent open 894 | |TCP CtrlChan(Cc) Setup | | | needs to launch 895 | |~~~~~~~~~~~~~~~~~~~~~~>| | > setup of the 896 | |CtrlChann(Cc) Setup Rsp| | | channel since 897 | |<~~~~~~~~~~~~~~~~~~~~~~| | | shutdown had 898 | <-- CcDes | | | | torn the 899 |tmlEvent(CcUp) | |tmlEvent(CcUp) | | channel down 900 |<--.--.--.--.--| |--.--.--.--.-->| / 901 | | | CcDes | 903 Legend: 904 PL --------> PL : Protocol layer messaging 905 PL --------> TML: TML API 906 TML ========> TML: Messaging between TML Layers 907 TML --.--.--> PL : Events/Notifications/Upcalls 908 TML ~~~~~~~~> TML: Internal protocol communication 910 Figure 5: Protocol Shutdown 912 6.3.Multicast Model 914 The TML layer provides support for multicast. In the ForCES model, 915 support is required to multicast to the FEs from a CE; in this case, 916 the CE is the source or root of the multicast and the FEs are the 917 leaves. 919 Support for multicast requires that a channel for supporting 920 multicast be opened between an FE and the CE. In the case of TCP 921 TML, the same channel is used for both unicast and multicast 922 messaging since multicast mode is simulated using unicast channels 923 in this case. Once the channel is open, FEs may join and leave 924 specified multicast groups. The first �multicast group join� 925 request from an FE to a CE for a specific multicast group results in 926 the creation of the group and an allocation of a group descriptor 927 (which is similar to a channel descriptor) for the group. The 928 �multicast group leave� request from an FE to the CE on a multicast 929 group with just that one member results in the group being removed 930 and the descriptor deallocated. A tmlWrite() on a unicast channel 931 descriptor results in a unicast message being sent to the FE 932 associated with the channel. A tmlWrite() on a group descriptor 933 results in multicast messaging. Figure 6 illustrates a multicast 934 scenario with 2 FEs, FE1 and FE2. In the first case, FE1 joins a 935 multicast group. In the second case, FE2 joins the same multicast 936 group, and leaves the group some time later. 938 Multicast Scenario with FE1: 939 FE1 PL FE1 TML CE TML CE PL 940 | | | | 941 | |STEADY STATE OPERATION | | \ Channel for 942 |<--------------|-----------------------|-------------->| > multicast msgs 943 | | | | | already exists 944 | | | | / via tmlOpen() 945 ~ ~ ~ ~ 946 ~ ~ ~ ~ 947 |tmlMcstGrpJoin | | | \ 948 |-------------->| | | | FE1 joins 949 | |Mcst Group Join Req | | | Multicast st | |======================>| | > Group. 1 join 950 | | |tmlJoinUpcall | | request for 951 | | |--.--.--.--.-->| | group, hence 952 | |Mcst Group Join Rsp |grp X={FE1} | | grp with grpDes 953 | |<======================| | / X created 954 | <-- Join OK | | | 955 | | | | 956 | | |tmlWrite(grp X)| \ 957 | | |<--------------| | Write to 958 | | | | > Multicast Grp. 959 ~ ~ ~ ~ | Msg sent to FE1 960 ~ ~ ~ ~ / only 962 Multicast Scenario with FE2: 963 FE2 PL FE2 TML CE TML CE PL 964 | | | | 965 | |STEADY STATE OPERATION | | 966 |<--------------|-----------------------|-------------->| 967 | | | | 968 | | | | 969 ~ ~ ~ ~ 970 ~ ~ ~ ~ 971 |tmlMcstGrpJoin | | | \ 972 |-------------->| | | | FE2 joins 973 | |Mcst Group Join Req | | > Multicast 974 | |======================>| | | Group. Grp 975 | | |tmlJoinUpcall | | already exists. 976 | | |--.--.--.--.-->| | Group members 977 | |Mcst Group Join Rsp |grp X={FE1,FE2}| | updated. 978 | |<======================| | / 979 | <-- Join OK | | | 980 | | | | 981 | | |tmlWrite(grp X)| \ 982 | | |<--------------| | Write to 983 | | | | > Multicast Grp. 984 | | | | | Msg sent to FE1 985 ~ ~ ~ ~ / and FE2. 986 ~ ~ ~ ~ 987 | | | | 988 |tmlMcstGrpLeave| | | \ 989 |-------------->| | | | FE2 leaves 990 | |Mcst Group Leave Req | | > Multicast 991 | |======================>| | | Group. Grp 992 | | |tmlLeaveUpcall | | membership 993 | | |--.--.--.--.-->| | updated. 994 | |Mcst Group Leave Rsp |grp X={FE1} | | 995 | |<======================| | / 996 | <-- Leave OK | | | 997 ~ ~ ~ ~ 998 ~ ~ ~ ~ 999 | | | | 1000 | | |tmlWrite(grp X)| \ 1001 | | |<--------------| | Write to 1002 | | | | > Multicast Grp. 1003 ~ ~ ~ ~ | Msg sent to FE1 1004 ~ ~ ~ ~ / only 1006 Legend: 1007 PL --------> PL : Protocol layer messaging 1008 PL --------> TML: TML API 1009 TML ========> TML: Messaging between TML Layers 1010 TML --.--.--> PL : Events/Notifications/Upcalls 1011 TML ~~~~~~~~> TML: Internal protocol communication 1013 Figure 6: Support for Multicast 1015 7. Security Considerations 1017 If the CE or FE are in a single box and network operator is running 1018 under a secured environment then it is up to the network 1019 administrator to turn off all the security functions. This is 1020 configured during the pre-association phase of the protocol. 1022 When the CEs, FEs are running over IP networks or in an insecure 1023 environment, this TML uses TLS [8] to provide security. The security 1024 association between the CEs and FEs MUST be established before any 1025 ForCES protocol messages are exchanged between the CEs and FEs. 1027 7.1.TLS Usage for this TML 1029 This section is applicable for CE or FE endpoints that use the TML 1030 with TLS [8] to secure communication. 1032 Since CE is master and FEs are slaves, the FEs are TLS clients and 1033 CEs are TLS server. The endpoints that implement TLS MUST perform 1034 mutual authentication during TLS session establishment process. CE 1035 must request certificate from FE and FE needs to pass the requested 1036 information. 1038 We recommend �TLS-RSA-with-AES-128-CBC-SHA� cipher suite, but CE or 1039 FE may negotiate other TLS cipher suites. TLS must be used for all 1040 control channel messages. TLS is optional for the data channel since 1041 data channel packets are not encrypted externally to the NE. 1043 This TML uses TLS to provide security when the NE is in an insecure 1044 environment. This is because IPsec provides less flexibility when 1045 configuring trust anchors since it is transparent to the application 1046 and use of Port identifiers is prohibited within IKE Phase 1. This 1047 provides restriction for IPsec to configure trust anchors for each 1048 application separately and policy configuration is common for all 1049 applications. 1051 8. IANA Considerations 1053 The TCP/IP TML needs to have a two well-defined TCP port numbers, 1054 which needs to be assigned by IANA. The control port is referred to 1055 as the TCP_TML_CONTROL_PORT. The data port is referred to as the 1056 TCP TML DATA PORT. 1058 9. References 1059 9.1.Normative References 1061 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 1062 October 1996. 1064 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 1065 Levels", RFC2119 (BCP), IETF, March 1997. 1067 3. Khosravi, et al., �Requirements for Separation of IP Control and 1068 Forwarding�, RFC 3654, November 2003. 1070 4. L. Yang, et al., � ForCES Architectural Framework�, RFC 3746, 1071 April 2004. 1073 5. L. Yang, et al., � ForCES Forwarding Element Functional Model�, 1074 work in progress�, July 2004, 1076 6. A. Audu, et al., � Forwarding and Control Element protocol (FACT)" 1077 draft-gopal-forces-fact-06.txt, February 2004. 1079 7. A. Doria, et al., �ForCES protocol specification�, draft-ietf- 1080 forces-protocol-00.txt, September 2004. 1082 9.2.Informative References 1084 8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. 1085 Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 1087 9. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 1088 Security over Stream Control Transmission Protocol", RFC 3436, 1089 December 2002. 1091 10. R. Stewart, et al., �Stream Control Transmission Protocol 1092 (SCTP)�, RFC 2960, October 2000. 1094 11. E. Kohler, M. Handley, S. Floyd, J. Padhye, �Datagram 1095 Congestion Control Protocol (DCCP)�, draft-ietf-dccp-spec-04.txt, 1096 June 2003. 1098 12. Floyd, S., �Congestion Control Principles�, RFC 2914, September 1099 2000. 1101 13. A. Doria, F. Hellstrand, K. Sundell, T. Worster, �General 1102 Switch Management Protocol (GSMP) V3�, RFC 3292, June 2002. 1104 14. H. Balakrishnan, et al. �The Congestion Manager�, RFC 3124, 1105 June 2001. 1107 15. H. Khosravi, S. Lakkavali, �Analysis of protocol design issues 1108 for open standards based programmable routers and switches� 1109 [SoftCOM 2004] 1111 16. S. Lakkavali, H. Khosravi, �ForCES protocol design analysis for 1112 protection against DoS attacks� [ICCCN 2004] 1114 10. Acknowledgments 1116 11. Authors' Addresses 1118 Hormuzd Khosravi 1119 Intel 1120 2111 NE 25th Avenue 1121 Hillsboro, OR 97124 1122 Phone: 1-503-264-0334 1123 Email: hormuzd.m.khosravi@intel.com 1125 Furquan Ansari 1126 101 Crawfords Corner Road 1127 Holmdel, NJ 07733 1128 USA 1129 Phone: +1 732-949-5249 1130 Email: furquan@lucent.com 1132 Jon Maloy 1133 Ericsson Research Canada 1134 8400 Boul Decarie 1135 Ville Mont-Royal, Quebec H4P 2N2 1136 Canada 1137 Phone: 1-514-345-7900 1138 Email: jon.maloy@ericsson.com 1140 Shuchi Chawla 1141 Intel 1142 2111 NE 25th Avenue 1143 Hillsboro, OR 97124 1144 Phone: 1-503-712-4539 1145 Email: shuchi.chawla@intel.com 1147 Copyright Statement 1149 Copyright (C) The Internet Society (year). This document is subject 1150 to the rights, licenses and restrictions contained in BCP 78, and 1151 except as set forth therein, the authors retain all their rights. 1153 This document and the information contained herein are provided on 1154 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1155 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1156 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1157 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1158 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1159 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.