FORCES A. Audu Internet-Draft Alcatel Expires: April 21, 2005 J. Hadi Salim Zynx Networks A. Doria ETRI October 21, 2004 Forwarding and Control Element Separation IP Transport Mapping Layer draft-audu-forces-iptml-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 21, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Audu, et al. Expires April 21, 2005 [Page 1] Internet-Draft ForCES-IPTML October 2004 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] Abstract This document defines the Forces-IPTML protocol that is designed to complement ForCES-PL (ForCES Protocol Layer) for communicating between Forwarding and Control Elements that make up a ForCEs-compliant network element, using IP transport technology (e.g. TCP/IP, SCTP/IP, UDP/IP). This protocol addresses all the requirements described in the Forces [0] requirements document. This document also specifies architectural attributes necessary in an implementation of Forces-IPTML to ensure correct and secure protocol operation. Audu, et al. Expires April 21, 2005 [Page 2] Internet-Draft ForCES-IPTML October 2004 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4.1 Interconnect Encapsulation . . . . . . . . . . . . . . . . 9 4.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Fail-Over Model . . . . . . . . . . . . . . . . . . . . . 10 5. ForCES-TML Message Overview . . . . . . . . . . . . . . . . . 12 5.1 Protocol Message Header Structure . . . . . . . . . . . . 12 5.1.1 Version . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.2 eType . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.3 Prio . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1.4 Message Classes and Types . . . . . . . . . . . . . . 13 5.1.5 Length . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1.6 Element Tag . . . . . . . . . . . . . . . . . . . . . 15 5.1.7 Source Tag . . . . . . . . . . . . . . . . . . . . . . 16 5.1.8 Destination Tag . . . . . . . . . . . . . . . . . . . 16 5.1.9 Transaction Sequence Number . . . . . . . . . . . . . 16 5.2 Service Data or Payload Structure . . . . . . . . . . . . 16 5.3 ForCES-TML Messages . . . . . . . . . . . . . . . . . . . 17 5.3.1 Association and Connection . . . . . . . . . . . . . . 17 5.3.1.1 Join Request . . . . . . . . . . . . . . . . . . . 17 5.3.1.2 Join Response . . . . . . . . . . . . . . . . . . 19 5.3.1.3 Leave Request . . . . . . . . . . . . . . . . . . 20 5.3.1.4 Leave Response . . . . . . . . . . . . . . . . . . 21 5.3.1.5 Join Multicast Address Request . . . . . . . . . . 21 5.3.1.6 Join Multicast Address Respone . . . . . . . . . . 22 5.3.1.7 Leave Multicast Address Request . . . . . . . . . 23 5.3.1.8 Leave Multicast Address Response . . . . . . . . . 24 5.3.2 Primitive Transfer Messages . . . . . . . . . . . . . 25 5.3.2.1 Reliable Data Transfer Request . . . . . . . . . . 25 5.3.2.2 Reliable Data Transfer Resposne . . . . . . . . . 25 5.3.2.3 Unreliable Data Transfer Request . . . . . . . . . 25 5.3.2.4 Unreliable Data Transfer Respone . . . . . . . . . 26 5.3.3 Security Association . . . . . . . . . . . . . . . . . 26 5.3.4 Management and Maintenance Messages . . . . . . . . . 26 5.3.4.1 Error Reporting . . . . . . . . . . . . . . . . . 26 5.3.4.2 HeartBeat Request . . . . . . . . . . . . . . . . 27 5.3.4.3 HeartBeat Acknowledge . . . . . . . . . . . . . . 27 5.3.5 Event Notification . . . . . . . . . . . . . . . . . . 27 5.3.5.1 Asunchronous Events Notification . . . . . . . . . 28 5.3.6 Vendor Specific Extensions . . . . . . . . . . . . . . 28 Audu, et al. Expires April 21, 2005 [Page 3] Internet-Draft ForCES-IPTML October 2004 5.3.6.1 Vendor Specific Data Request . . . . . . . . . . . 28 5.3.6.2 Vendor Specific Data Response . . . . . . . . . . 29 5.3.7 ForCES-TML Interfaces . . . . . . . . . . . . . . . . 29 5.3.7.1 ULP-to-TML Interface . . . . . . . . . . . . . . . 29 5.3.7.2 TML-to-ULP Interface . . . . . . . . . . . . . . . 31 5.3.8 Scenarios . . . . . . . . . . . . . . . . . . . . . . 32 5.3.9 Security Considerations . . . . . . . . . . . . . . . 32 5.3.10 IANA Considerations . . . . . . . . . . . . . . . . . 32 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 33 6.2 Non-Normative References . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33 A. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . 36 Audu, et al. Expires April 21, 2005 [Page 4] Internet-Draft ForCES-IPTML October 2004 2. Introduction Network Elements (NE) such as routers are becoming more and more complex as they try to cope with demanding features like policy based routing, firewalls and NATs, and QoS aware routing. As a result, issues like scalability, (the ability to cost-effectively grow a network as demand increases) and programmability (the ability to dynamically program the network for some specific services by programming the NEs that handle those services) become very important. The ForCEs protocol has been specified to help resolve these issues by decoupling control and forwarding parts of a network element, and also adding programmability features to the NE. It is also important for the ForCES protocol to run over varying transport media. To this end, ForCES has been split into two layers: the Protocol Layer (PL) and the Transport Mapping Layer (TML). The PL is generic and common to all implementations of ForCES and is standardized by this IETF document. The TML is defined in other documents. There is a TML generated per transport medium. The default TML is the IP-TML that corresponds to a TCP/IP transport medium. The (PL) sits on top of (and receives services from) the (TML). This document specifies the ForCES-IPTML layer. Forces-PL has been designed for use in a redundant environment, for relaying messages between control elements (CE) and forwarding elements (FE) distributed in a network as found in ForCEs. ForCES-IPTML will make the interaction between CEs and FEs as transparent as possible. Audu, et al. Expires April 21, 2005 [Page 5] Internet-Draft ForCES-IPTML October 2004 3. Definitions The following definitions are taken from [FORCES-REQ][RFC3654], and [FE-MODEL][I-D.ietf-forces-model] Forwarding Element (FE): - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed by a CE via the ForCES protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. Control Element (CE): - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs how to process packets. CEs handle functionality such as the execution of control and signaling protocols. Pre-association Phase: - The period of time during which a FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element and delivering that information to the FE and CE. Post-association Phase: - The period of time during which a FE has the information specifying what CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another. ForCES Post-Association Phase Protocol: - The protocol used for post-association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. The term ForCES protocol may refer to a suite of protocols that are used to exchange control information as well as redirect data packets between the CEs and FEs. FE Manager: - A logical entity that operates in the pre-association phase and is responsible for determining with which CE(s) an FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, an FE manager might be physically combined with any of the other logical entities mentioned in this section. CE Manager: - A logical entity that operates in the pre-association phase and is responsible for determining with which FE(s) a CE should communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre-association phase protocol (see below) to determine which FE to use. Being a logical entity, a CE manager might be physically Audu, et al. Expires April 21, 2005 [Page 6] Internet-Draft ForCES-IPTML October 2004 combined with any of the other logical entities mentioned in this section. Pre-association Phase Protocol: - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) that used within the ForCES protocol. However, the two capability discovery mechanisms may utilize the same FE model. ForCES Network Element (NE): - An entity composed of one or more CEs and one or more FEs. To entities outside a NE, the NE represents a single point of management. Similarly, a NE usually hides its internal organization from external entities. ForCES Protocol Element (PE): - A Forwarding Element or a Control Element that speaks the ForCES protocol. LFB (Logical Function Block) class (or type): -- A generic template representing a fine-grained, logically separable and well-defined packet processing operation in the datapath. LFB class is the basic building block of the FE model. FE Model (FEM): - Modeling/Organization of LFBs in the Forwarding plane. CE-TML: - Transport Mapping Layer resident in the control element. FE-TML: - Transport Mapping Layer resident in the forwarding element. ULP: - Upper Layer Protocol. Refers to the protocols using the TML layer. These will be the ForCES-PL in the CE and the FE. Audu, et al. Expires April 21, 2005 [Page 7] Internet-Draft ForCES-IPTML October 2004 4. Protocol Overview ForCES is a framework consisting of set of protocols representing the forwarding and control elements in the form of an extensible model [FRAMEWK][FE-MODEL]. CEs handle control, signaling and management protocols, while FEs perform forwarding functions. CEs control the behavior of FEs in a master/slave fashion. To handle the transport of data and control between the CEs and FEs, ForCES has specified two protocol entities: ForCES-Protocol Layer (Froces-PL) and the Transport Mapping Layer (Forces-TML). The ForCES-PL is independent of the transport interconnect type, but it requires service from the ForCES-TML to communicate with its peer. ForCES-PL and ForCES-TML Connecting CEs and FEs +-----------+ | Forces-PL | CE | | +-----------+ | TML | Control Plane +-----------+ | | | | | | uw1 | | | | | | +---------------+ | | | | +---------------+ | +-uw2----------+ | | +--------------+ | | | | | | | | | +--mw1--------+-|--------------+ | | | | | | | | | | | | +--mw2--------+------------+ | | | | | | | | | | | +-----------+ +-----------+ | TML | | TML | +-----------+ . . . .. +-----------+ Forwarding | Forces-PL | | Forces-PL | Plane +-----------+ +-----------+ FE1 FEN Legend: Forces-PL - Protocol Layer TML - Transport Mapping Layer uwi - unicast wire with priority i uwj - unicast wire with priority j mwk - multicast wire with priority k mwl - multicast wire with priority l Audu, et al. Expires April 21, 2005 [Page 8] Internet-Draft ForCES-IPTML October 2004 Figure 1 In Figure 1, virtual wires or links connect a CE in the control plane to a set of FEs (FE1 to FEN) in the forwardding plane. There are two types of links : unicast and multicast. Unicast links carry unicast data or control between endpoints. Multicast links carry point-to-multipoint data or control. Each link can be assigned a priority. The links could be of different quality of service (e.g. reliable, or unreliable), but they are all congestion aware. This allows the protocol to separate control and data traffic into different streams, to reduce the threat of Denial of Service (DoS) attacks on the survivability of the system and making the protocol more robust. In a redundant system, CE s and FE s will be replicated, with one set being active at a particular time while the other is in standby. The TML provides the following services to the forces-pl: reliable service and unreliable service security (including end-point authentication, message authentication, confidentiality) Congestion control Unicast, multi-cast, and broadcast Timeliness (?) Redundancy (?) Stream prioritization (?) The ForCES-TML protocol also supports a notion of distributed IPC mechanism by providing services required for replication, high availability and fail-over (redundancy) to the ForCES-PL in a distributed network element environment. 4.1 Interconnect Encapsulation The Forces-PL protocol is independent of the Interconnect Layer. It makes no assumptions about the interconnect layer and uses interconnect independent addressing in its common header and API. All interconnect specific properties are encapsulated by the TML. 4.2 Reliability Separate Control and Data channels The ForCES NEs are subject to Denial of Service (DoS) attacks [FORCES-REQ, Section 7 #15]. A malicious system in the network can flood a ForCES NE with bogus control packets such as spurious RIP or OSPF packets in an attempt to disrupt the operation of and the Audu, et al. Expires April 21, 2005 [Page 9] Internet-Draft ForCES-IPTML October 2004 communication between the CEs and FEs. In order to protect against this situation, the ForCES protocol uses separate control and data channels for communication between the CEs and FEs. The data channel carries the control protocol packets such as RIP, OSPF messages as outlined in [FORCES-REQ] Section 7 #10, between the CEs and FEs. The other Forces-PL messages, which are used for configuration/capability exchanges, event notification, etc, are carried over the control channel. It may be necessary for the data channel to be set up as an unreliable but congestion aware channel. The control channel is set up as a reliable channel. The channels are set up via the use of the Join process (see section 5.1.1). Each channel has a priority value attached to it. This is used to give preferential treatment to the traffic carried on the channels. For example, OSPF packets (encoded as PE Traffic Maintenance messages) could be given higher priority than ping packets on the data channel. The use of separate control and data channels, channel priority along with rate limiting mechanisms on the FE provides robustness to the Forces-PL protocol against DoS attacks. 4.3 Fail-Over Model The Forces-PL protocol provides CE fail-over functions in order to support high availability of the network element [RFC3654]. The CE-SET (see section 4.1.4) is a list of CEs that reside within a Network Element (NE) as a cooperating unit. Likewise, the FE-SET is a list of FEs that reside in an NE as a cooperating unit. The following are the high-availability mechanisms that are provided by Forces-PL protocol. Strong Consistency: In strong consistency mode, the FE sends all asynchronous notifications/ control protocol packets to the primary and backup CEs in the CE set. By doing this, the FE enables both the primary and backup CEs to keep the state synchronized. Weak Consistency (Fail-over): In this mode, the FE communicates directly with the primary CE. If the primary CE fails, the FE starts communicating with the backup CE. In an active-standby redundant setting, the first CE to be active will be the primary CE, while the other will be in standby mode. Also in a replicated FE set, the first set of FEs to be activated will be the primary set. In all the above cases, CE (including primary and backup CEs) and FEs are pre-configured to perform such activities as part of pre-association phase. Also, the TML does not assign different treatment status to the links used by primary or backup CEs or FEs Audu, et al. Expires April 21, 2005 [Page 10] Internet-Draft ForCES-IPTML October 2004 other than the priorities assigned to the links during association. In other words, primary or standby roles are not determined by the TML. Audu, et al. Expires April 21, 2005 [Page 11] Internet-Draft ForCES-IPTML October 2004 5. ForCES-TML Message Overview Forces-TML protocol messages are made up of two parts: the common header, and the message body or service payload part. This section describes the details of the common header and payload structure. These messages are used to communicate between TML protocol peers and are sent network Byte Ordered across the network. 5.1 Protocol Message Header Structure Forces-PL protocol Header is fixed size and contains the following fields. Forces TML Protocol Message Header 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |vers |eType | prio| reservd | msgClass | msgType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination-Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 5.1.1 Version The version field (4-bits) contains the version of the Forces-PL protocol supported by the implementation. The current supported version is : value 0x01 Protocol elements implementing the Forces-TML protocol SHOULD provide backwards compatibility with prior versions of the protocol. 5.1.2 eType This field identifies the format of data exchange used between the communicating endpoints. Valid values include: Value Description . 0x1 Plain TLV 0x2 XML 0x3 BINARY-XML Audu, et al. Expires April 21, 2005 [Page 12] Internet-Draft ForCES-IPTML October 2004 5.1.3 Prio This three bit field allows eight(8) different levels of priority to be assigned to different packet streams. This enables the different packet streams to be given preferential treatments based on the priority. The default setting is 0 (for normal priority) 5.1.4 Message Classes and Types Forces-TML's messages are grouped into five (6) classes namely: Management Messages used for initializing TML layer, and monitoring its status. Connection and Association messages, which help establish logical connections between FE-TMLs and CE-TMLs. Security Association messages, used for authenticating user endpoints. Boundary Primitive Transport Messages are used by FPL to send and receive messages from its peer opaquely via the TML layer. Event Handling messages are used to report asynchronous events. Application and Vendor Specific messages which are used to exchange TML-application data between CE-TML and FE-TML application endpoints. They are used to extend the protocol beyond its current capabilities. Each class consists of a set of related message types. The valid message classes are: Message Class: 8 bits (unsigned integer) 0 TML Management messages 1 Connection and association (CA) Messages 2 Security Association (SA) Messages 3 Boundary Primitive Transport (PT) Messages 4 Event Handling (EH) Messages 5 Application and Vendor Specific (AV) Messages 6- 255 Reserved by IETF for future use The message types (5 bits) for the defined message classes are as follows: Message Type for Management ( TM ) Message Class 0 Reserved 1 Initialize/Reset Request Audu, et al. Expires April 21, 2005 [Page 13] Internet-Draft ForCES-IPTML October 2004 2 Initialize/Reset Response 3 Shutdown Request 4 Shutdown Response 5 Status Request 6 Status Response 7 Heartbeat 8 Heartbeat Ack 9-255 Reserved by IETF for future use Message Type for Connection and Association (CA) Message Class 0 Reserved 1 Join Request 2 Join Response 3 Leave Request 4 Leave Response 5 Join MCastAddr Request 6 Join MCastAddr Response 7 Leave MCastAddr Request 8 Leave MCastAddr Response 9-255 Reserved by IETF for future use Message Types for Primitive Transfer Messages (PT) Message Class 0 Reserved 1 Data Request Reliable Message 2 Data Response Reliable Message 3 Data Request Unreliable Message 4 Data Response Unreliable Message 5-255 Reserved by IETF for future use Message Types for Security Association (SA) Message Class 0 Reserved 1 Authentication Request 2 Authentication Response 3 Audu, et al. Expires April 21, 2005 [Page 14] Internet-Draft ForCES-IPTML October 2004 4-255 Reserved for future use by IETF Message Types for Application and Vendor Specific (AV) Message Class 0 Reserved 1 AV-Data Request 2 AV-Data Response 3-255 Reserved for other vendor specific messages 5.1.5 Length This denotes the length of the message in octets, including the message header part. 5.1.6 Element Tag This is used to identity a CE or an FE element in the NE for the purpose of exchanging data within the system. It is made up of a SET number (identifying the group or set the source element belongs to), and a unique Identifier of that element in the set. Thus for a CE or FE, the Element-Tag would look like the following: Showing Element Tags for CE and FE 0 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ a) | CE-Set Number | CE-Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ b) | FE-Set Number | FE-Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 During the pre-association phase, the CEs and FEs are configured by the CE-Manager and FE-Manager respectively into groups or sets. A group can contain one or more elements, and it is identified by a group number (CE-SET or FE-SET number). Any element within a group Audu, et al. Expires April 21, 2005 [Page 15] Internet-Draft ForCES-IPTML October 2004 also has a number to identify it. The combination of this identifier and the set number is the element-tag number. 5.1.7 Source Tag This denotes the element-tag of the source of the message being exchanged between a communicating CE and FE peer. 5.1.8 Destination Tag This denotes the element-tag of the destination or sink of the message being exchanged between a communicating CE and FE peer. 5.1.9 Transaction Sequence Number This 32-bit field uniquely identifies a transaction between an FE-TML and a CE-TML. When a TML endpoint makes a request it generates a TSN for use in the request message; the other endpoint copies this same TSN number in its reply message. 5.2 Service Data or Payload Structure Forces-TML protocol messages consist of the Common Message Header described in the previous section, followed by zero or more variable length parameters, as defined by the message type. This constitutes the Payload or Service Data. All Forces-TML messages are 32-bit aligned. Examples of the service data are the following: LFB configuration, status and events as carried in Primitive transfer messages FE capability and topology data (carried in Primitive transfer messages) Control protocol packets (also carried in Primitive transfer messages) TML configuration and association set up messages The variable length parameters in the payload are defined in a Tag-Length-Value (TLV) format as shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Tag | Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Parameter Value / \ \ Audu, et al. Expires April 21, 2005 [Page 16] Internet-Draft ForCES-IPTML October 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mandatory parameters MUST be placed before optional parameters in a message. Parameter Tag: 16 bits The Tag field is a 16-bit unique identifier of the type of the parameter. It takes a value of 0 to 65534. Appendix-1 lists all used values of the Tag and related messages. Values other than those defined in specific parameter description are reserved for use by the IETF. Parameter Length: 16 bits The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. The Parameter Length does not include any padding bytes. Parameter Value: variable-length The Parameter Value field contains the actual information to be transferred in the parameter. The total length of a parameter (including Tag, Parameter Length and Value fields) MUST be a multiple of 4 bytes. If the length of the parameter is not a multiple of 4 bytes, the sender pads the parameter at the end (i.e., after the Parameter Value field) with all zero bytes. The length of the padding is NOT included in the parameter length field. A sender MUST NEVER pad with more than 3 bytes. The receiver MUST ignore the padding bytes. 5.3 ForCES-TML Messages This section defines the messages and their parameter contents. 5.3.1 Association and Connection These messages originate from the FE and CE entities in the ULP (Upper Layer Protocol). They are exposed to the TML to allow the TML to allocate the necessary resources needed to form the association between peer ULP entities. 5.3.1.1 Join Request This allows a CE or an FE to join a CE-set. The TML uses the information passed in to allocate management resources necessary for the CE-FE unicast-association. The message contains the requester's identity (element tag, or address) that was configured during pre-association. At a given point, CEs from one CE set can communicate with an FE. The FE has to know which CE's requests it can accept. This information is configured during the pre-association phase, during which a list of CEs allowed to control the FE is configured in the FE. The FE uses this CE-list to send the join request. It first tries one of the CE's in the list and if not Audu, et al. Expires April 21, 2005 [Page 17] Internet-Draft ForCES-IPTML October 2004 successful, it tries the next CE in the list. If all of the CEs in the list are tried without success, the FE should start over again until Retry timer expires. The format of the JOIN Message payload is as follows: Join Request 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x10) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source element | Destination element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x20) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Address o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 The Join-Request message has the following parameters: Source Element: This is the element-tag of the source of the Join request. Destination Element: This is the element-tag of the target of the request. Address: The Interconnect dependent unique address of the FE. The tag value determines the type of addressing used. After receiving a join request message, the TML performs the following operations. If the source of the Join request is a CE, the TML will match the target CE-Set in the request with those in its data base. If found, the TML sends the request to the target CE of the Join request. If not found, the TML allocates resources for the target CE-Set and sets the requesting CE ID as the controlling CE for this SET. [ Note: This is probably better done by having a Create-CE-Set message. However, his part should be removed because CE-to-CE communication is beyond scope of ForCEs] If the source of the request is an FE, the FE's TML sends the Join Request to the target CE's TML. The target CE's TML will assign an association ID and forward the request (including the association ID) to the target CE if possible. This association ID Audu, et al. Expires April 21, 2005 [Page 18] Internet-Draft ForCES-IPTML October 2004 will be used to refer to future interaction between this CE-FE pair. If the request can't be delivered to the target TML, the source TML rejects the request with a proper reason code. Also, if the request can't be delivered to the target CE, the target TML will send a reject with the appropriate reason code. (See Leave Response) 5.3.1.2 Join Response On receiving a Join Response message from CE, the TML performs the following: Matches the association-ID component of the message against those in its database. If found, the TML will forward the response to the target FE's TML. If not found, the TML rejects it with [system error failure or Leave Response, with appropriate reason code]. The TML at the target FE will forward the response to the FE, after noting the association ID in the message for future use. It the TML can't deliver the message to the FE, the TML rejects the message with Leave Response with appropriate reason code. The TML at the target FE will forward the response to the FE, after noting the association ID in the message for future use. It the TML can't deliver the message to the FE, the TML rejects the message with Leave Response with appropriate reason code. The format for the JOIN RESPONSE message payload is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x50) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Element ID | Destination Element ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Expiry Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FE Behavior | Behave Expiry Timer(opt)| Prio| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Audu, et al. Expires April 21, 2005 [Page 19] Internet-Draft ForCES-IPTML October 2004 Association-ID: This uniquely identifies the stream or virtual connection (wire) between the FE and CE. Further communication between this FE-CE peer uses the stream. FE Behavior: This defines the FE behavior when all the CEs are down. A value of 1 indicates the FE should continue forwarding packets; a value of 0 indicates the FE should stop forwarding packets when the CEs are down. Heartbeat Interval: This gives the time interval for the heartbeat messages sent from the CE to the FE in milliseconds. Association Expiry Timer: This gives the timer value in milliseconds after which if the FE does not receive any heartbeat messages from the CE it should consider the association with the CE to have expired (CE DOWN). Behave Expiry Timer: This is an optional timer value, which applies in case the FE behavior is to continue forwarding packets when CEs are down. This value indicates the time in seconds for which the FE should continue forwarding packets without associations with any CEs. Value range from 0x0 (don't forward) to 0xffff (forward forever). Priority: This is the priority being requested for the association that may result from a successful join. Note that each FE can set up multiple unicast associations by making multiple Join requests, each with a different priority value. This allows an FE to set up an association for control information and another one for user data exchange between the CE and the FE. For this version of ForCES-PL/ForCEs-TML, the maximum limit is two (2) associations per FE. 5.3.1.3 Leave Request The FE can leave by sending Leave request to CE. The CE's upon receiving such request releases the associated resources assigned for the FE. The FE's TML, on getting this request, will forward it to the target CE's TML based on the underlining association. On getting the request, the target TML will forward it to the target CE for processing. The format for the LEAVE Message parameters is same as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xa) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Audu, et al. Expires April 21, 2005 [Page 20] Internet-Draft ForCES-IPTML October 2004 | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o INFO String* o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The reason parameter indicates the reason the FE (or CE) is leaving the NE. Valid values are as follows: The optional INFO String parameter can be any meaningful 8-bit character string (up to 255 characters). This may be used for debugging purposes. 5.3.1.4 Leave Response When an FE has made a request to leave the CE, the CE generates an acknowledgment to the FE in the form of a Leave Response message. A CE could have generated the Leave Request. In this case, the (active) CE in the CE-set will generate the response sent to the leaving CE. (NOTE: Currently, CE-CE communication is out of scope and the mode if CE-CE communication is entirely proprietary) If a CE needs to reject a join request from a FE for some reason, it sends a Leave Response Message to the FE as well (Refer to Section 5.1.2). In any case, this Leave Response will arrive at the sender's TML, which then forwards the response to the target. The TML will then remove the association ID resources for that connection from its database. The format of the Leave Response message is the same as in the Leave Request message (See 5.1.3) 5.3.1.5 Join Multicast Address Request This used by the FE or CE to join a multicast address group. Messages sent from a group member will be sent to all other members in the group. The format of the JOIN MCAST-ADDR Message payload is as follows: Audu, et al. Expires April 21, 2005 [Page 21] Internet-Draft ForCES-IPTML October 2004 Join MCast Address Request 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x20) | Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Address < +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x10) | Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast_Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | prio| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Address: The Interconnect dependent unique address of the FE. The tag value determines the type of addressing used. Mcast_Address: This is the multicast group address being joined. Link Priority: This is the value of the priority for the link that may result from the join request. The value set here will be reflected in the Prio header bits for data exchanges between source and sink using the requested multicast address. On getting this message, the TML performs the following operations: The TML at the FE will forward the request to the target CE's TML. The TML at the CE will try to match the address group in the message with the list in its database. If successful, the sender's unique address contained in the message is added to the address group. A Join Multicast Address Response message is then sent to the requestor. If the address group doesn't exist however, the TML will reply with a Leave Multicast Address Response with the appropriate reason code. 5.3.1.6 Join Multicast Address Respone This is the response sent to a requester after a successful multicast address Join process. The format of the body of this message is the same as in the request (see 5.1.5). Note this message will typically be sent by the TML (Transport Audu, et al. Expires April 21, 2005 [Page 22] Internet-Draft ForCES-IPTML October 2004 layer). If the join request was not successful for some reason, a Leave Multicast Address response (see 5.1.8) will be sent back to the requester. On getting this message, the TML performs the following operations: CE TML. This message is generated by the CE's TML. It sends the response message to the target FE's TML, which then forwards it to the FE. After a successful multicast address join, any message sent from the CE to the group address will be replicated to each FE on the group address list. 5.3.1.7 Leave Multicast Address Request This message is sent by a CE or an FE endpoint to signal its intention to stop receiving multicast messages sent to a particular group address. The format of the LEAVE MCAST_ADDR Message payload is as follows: Leave Multicast Address Request 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x21) | Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast_Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x0a) | Length (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Mcast-Adress: This is the multicast address being vacated. Reason: Reason for leaving the group On getting this message, the TML performs the following operations: Audu, et al. Expires April 21, 2005 [Page 23] Internet-Draft ForCES-IPTML October 2004 TML at the FE simply forwards message to the target CE's TML. On getting the request, TML at the CE will remove the requestor's unigue address from the address group list (if the address group is present). It then sends a Leave Multicast Address Response to the requestor, with the appropriate reason code. 5.3.1.8 Leave Multicast Address Response This is sent to the requesting FE or CE to acknowledge a successful discontinuation of the requestor's membership in a multicast address group. It can also be sent in the event of an unsuccessful join- multicast-address request. Thereafter, messages sent to that multicast address will not be delivered to that endpoint. The LEAVE MCAST-ADDR response message contains the following parameters: The format for the LEAVE MCAST-ADDR Message parameters is same as follows: Leave Multicast Address Response 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x20) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast_Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xa) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reason | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x4) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 INFO String* 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 Reason: The reason for leaving the multicast group. Info-String: The optional INFO String parameter can be any meaningful 8-bit character string (up to 255 characters). This may be used for debugging purposes. Audu, et al. Expires April 21, 2005 [Page 24] Internet-Draft ForCES-IPTML October 2004 Valid reasons for leaving an address group are as follows: Note: This message will typically be sent by the TML layer if present. The TML at the FE, on getting this response, forwards the message to its FE. 5.3.2 Primitive Transfer Messages These messages are used by the ULP to send application messages opaquely via the TML. The sender must have successfully created an association with a receiving peer (via the JOIN, or Join Multicast process). For example, CEs and FEs will use these messages to exchange capability information, configuration information, etc. 5.3.2.1 Reliable Data Transfer Request This message is used by the TML layer to send application data to the peer TML in a reliable mode. The protocol data of this message is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x30) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 Protocol Data 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The protocol data will contain packets carrying requests or responses between peer ULP protocols. 5.3.2.2 Reliable Data Transfer Resposne TBD 5.3.2.3 Unreliable Data Transfer Request This is used by the TML layer to send application data to the peer TML via the unreliable (i.e. UDP-like) mode. The protocol data of this message is as follows: Audu, et al. Expires April 21, 2005 [Page 25] Internet-Draft ForCES-IPTML October 2004 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x30) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 Protocol Data o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3.2.4 Unreliable Data Transfer Respone TBD. 5.3.3 Security Association CEs and FEs have to be authenticated by the CE's TML before communication can occur between peer endpoints. The SA messages are used to provide authentication for the endpoints. [Details filled in later] 5.3.4 Management and Maintenance Messages These set of messages are used to manage the TML layer itself. 5.3.4.1 Error Reporting The Error TLV is used to notify the ULPs in CE or FE of an error associated with an incoming synchronous Request message. For example, the message might be unexpected, given the current state, or a parameter value might be invalid. This Error TLV can be sent as a result of a request (synchronous), or it could be triggered asynchronously as a result of asynchronous events occuring in the system. The format of the Error TLV is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0xc) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Audu, et al. Expires April 21, 2005 [Page 26] Internet-Draft ForCES-IPTML October 2004 The Error Code parameter indicates the reason for the error. 5.3.4.2 HeartBeat Request CE-TML periodically polls each FE-TML to ensure that it is operational. Any errors will be reported via the event asynchronous event handling. A CE-TML starts generating these messages after the FE-TML has successfully authenticated and joined the CE-TML. The timers for these messages are configurable during pre-configuration and can be different for the active and standby CE-TMLs. The heartbeat interval for a standby CE-TML can be much larger than that of the active CE-TML. An optional Heartbeat Data parameter may be sent in the heart beat message. Its contents are defined by the sending node and are simply echoed back by the receiving FE via the HB-ACK message (see below). Examples of values encoded in the Heartbeat Data field by FE-TMLs could include a Heartbeat Sequence Number or Timestamp. The receiver of a Heartbeat message does not process this field as it is only of significance to the sender. The receiver MUST respond with a Heartbeat Acknowledgement message. The format for the Heartbeat Message is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x9) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O Heartbeat Data 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3.4.3 HeartBeat Acknowledge The receiving FE simply echo's the original heartbeat message back to the sender. 5.3.5 Event Notification Various events in the data path can be monitored for by the FE and reported to the CE. The CE must first inform the FE which of these Audu, et al. Expires April 21, 2005 [Page 27] Internet-Draft ForCES-IPTML October 2004 events it is interested in through a registration process. 5.3.5.1 Asunchronous Events Notification This is used to report asynchronous events occurring in the FE. These could be overall FE errors, Port/Link errors or Logical Component specific events. The message contains the following: The format of the ASYNC-NTFY message is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1e) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Type | Event ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Logical Component Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x7) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Diagnostic Info o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Valid values of the Event ID are as follows: 5.3.6 Vendor Specific Extensions This allows vendor specific TML extension messages to be transported opaquely over the ForCES-TML protocol. This way, currently unknown TML functionality (outside of those already specified) can be expressed. 5.3.6.1 Vendor Specific Data Request TMLs may use this message to pass any information that is not to be consumed by TML protocol proper to each other. This message is used by the extension module of a TML to send extension specific data to peer TML's extension module. Payload structure for Vendor Specific (VS) Request is as shown below. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Audu, et al. Expires April 21, 2005 [Page 28] Internet-Draft ForCES-IPTML October 2004 | Tag (0x4e) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o Data to be transported o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.3.6.2 Vendor Specific Data Response This is used by the extension module in the TML that receives an Inter-TML-extension-module communication message to acknowledge the reception to the original sender. The format of this message is same as for VS-DATA Request. 5.3.7 ForCES-TML Interfaces Force-TML protocol interfaces with an upper-layer protocol (in this case the Forces-PL), and a lower protocol (in this case, the IP/TCP/UDP/SCTP protocols). The upper layer protocol shall request services passing primitives to the TML layer and shall receive notifications from the TML layer for various events. The primitives described in this section should be used only as a guideline in implementing TML APIs. 5.3.7.1 ULP-to-TML Interface The following describe the ULP/TML interface functions. These are the basic functions the TML must perform to support inter-ULP communication. Initialize:: Format: Initialize() Return -> Local instance name of the TML. This primitive allows TML to initialize its internal structures and allocate resources to support the ULP peer communication. Authenticate Endpoints:: Format: Authenticate(parameters yet to be determined) Return -> Pass or Fail This is used to authenticate the endpoints prior to them engaging in communication. In this exercise, the CE Audu, et al. Expires April 21, 2005 [Page 29] Internet-Draft ForCES-IPTML October 2004 and its TML are the trusted entities. All FEs and FE-TMLs have to be authenticated using this primitive. Details are TBD Join (or Associate):: Format: Join(source address, destination address) Return -> Pass or Fail This is used to create a unicast association between the source address and the destination address that resides on the peer TML endpoint. Join Multicast (or Associate Multicast):: Format: Join-Multicast(source address, multicast-group-Address) Return -> Pass or Fail This is used to create (if not already created) and register source address with multicast-group-address handling for the purpose of message distribution.An association will be established between the CE TML and the appropriate FE TML for the purpose of message distribution. Leave:: Format: Leave(source address) Return -> Pass or Fail This is used by an entity in the ULP to leave a unicast association the entity currently belongs in. Leave Multicast:: Format: LeaveMulticast(source address, multicast-group-address) Return -> Pass or Fail This is used by an entity in the ULP to leave the specified multicast group association the entity currently belongs in. Shutdown:: Format: Shutdown(association/stream ID) Return -> Pass or Fail Gracefully close an association or stream. Any locally queued data will be delivered to the peer. A success code will be returned on successful termination of the association. If a failure results, an error code will be returned. Abort:: Format: Abort(association or stream-ID, reason-code) Audu, et al. Expires April 21, 2005 [Page 30] Internet-Draft ForCES-IPTML October 2004 Return -> Result Code (Pass or Fail) Ungracefully close down an association or stream. Any locally queued user data will discarded, and an abort message with the reason code sent to the peer.If successful, a success code will be return, else, an error code will be returned. Send Reliable :: Format: SendReliable(association-id, buffer-address, byte-count, destination-address) Return = Result Code This is used to send user data between peer ULPs via TML using a reliable mechanism. In this document, the destination-address will be the element tag of the target. (i.e. CE-SET:CE-Identifier, or FE-SET:FE-Identifier). Send Unreliable:: Format: SendUnreliable(buffer-address, byte-count, destination-address) Return -> Result Code (Pas or Fail) This is used to send user data between peer ULPs via TML using an unreliable mechanism. Receive:: Format: Receive(association-id, buffer-address, buffer-size) Return -> byte count delivered This is used by ULP to read user data in TML in-queue into specified buffer in ULP. Size of message read is returned. Status:: Format: Status(association-id) Return -> Status data of the association or stream This primitive will return a data block containing status information of the specified stream or association. .association connection state, .association error counts, .destination address 5.3.7.2 TML-to-ULP Interface The following describe the TML/ULP interface functions. These are the basic functions the TML must perform to asynchronously provide data to the ULP. [TBD] Audu, et al. Expires April 21, 2005 [Page 31] Internet-Draft ForCES-IPTML October 2004 5.3.8 Scenarios TBD 5.3.9 Security Considerations [Yet to be determined] 5.3.10 IANA Considerations [Yet to be determined] Audu, et al. Expires April 21, 2005 [Page 32] Internet-Draft ForCES-IPTML October 2004 6. References 6.1 Normative References [I-D.ietf-forces-model] Yang, L., "ForCES Forwarding Element Model", draft-ietf-forces-model-03 (work in progress), July 2004. [I-D.ietf-forces-protocol] Doria, A., "ForCES Protocol Specification", draft-ietf-forces-protocol-00 (work in progress), September 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", RFC 3654, November 2003. [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004. 6.2 Non-Normative References Authors' Addresses Alex Audu Alcatel 3400 West Plano Parkway Plano Texas USA Phone: EMail: alex.audu@alcatel.com Jamal Hadi Salim Zynx Networks Ottawa, Ontario Canada Phone: EMail: hadi@zynx.com Audu, et al. Expires April 21, 2005 [Page 33] Internet-Draft ForCES-IPTML October 2004 Avri Doria ETRI Phone: EMail: avri@acm.org Audu, et al. Expires April 21, 2005 [Page 34] Internet-Draft ForCES-IPTML October 2004 Appendix A. Acknowledgement TBD Audu, et al. Expires April 21, 2005 [Page 35] Internet-Draft ForCES-IPTML October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Audu, et al. Expires April 21, 2005 [Page 36]