Internet DRAFT - draft-audu-forces-iptml
draft-audu-forces-iptml
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]
