draft-ietf-forces-tcptml-00.txt   draft-ietf-forces-tcptml-01.txt 
Hormuzd Khosravi Hormuzd Khosravi
Internet Draft Shuchi Chawla Internet Draft Shuchi Chawla
Document: draft-ietf-forces-tcptml-00.txt Intel Corp. Document: draft-ietf-forces-tcptml-01.txt Intel Corp.
Expires: August 2005 Furquan Ansari Expires: January 2006 Furquan Ansari
Working Group: ForCES Lucent Tech. Working Group: ForCES Lucent Tech.
Jon Maloy Jon Maloy
Ericsson Ericsson
February 2005 July 2005
TCP/IP based TML (Transport Mapping Layer) for ForCES protocol TCP/IP based TML (Transport Mapping Layer) for ForCES protocol
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance have been or will be disclosed, and any of which he or she becomes
with RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in reference material or to cite them other than as ``work in
progress.'' progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [2]. this document are to be interpreted as described in [2].
Abstract Abstract
This document defines the TCP/IP based TML (Transport Mapping Layer) This document defines the TCP/IP based TML (Transport Mapping Layer)
for the ForCES protocol. It explains the rationale for choosing the for the ForCES protocol. It explains the rationale for choosing the
transport protocols and also describes how this TML addresses all transport protocols and also describes how this TML addresses all
the requirements described in the Forces [3] requirements and ForCES the requirements described in the Forces [3] requirements and ForCES
protocol [7] document. protocol [7] document.
Table of Contents Table of Contents
1. Definitions.....................................................3 1. Definitions.....................................................2
2. Introduction....................................................3 2. Introduction....................................................3
3. Protocol Framework Overview.....................................4 3. Protocol Framework Overview.....................................3
3.1.1. The PL layer................................................5 3.1.1. The PL layer................................................5
3.1.2. The TML layer...............................................5 3.1.2. The TML layer...............................................5
4. TCP/IP TML Overview.............................................5 4. TCP/IP TML Overview.............................................5
4.1. Rationale for using TCP/IP....................................6 4.1. Rationale for using TCP/IP....................................5
4.2. Separate Control and Data channels............................6 4.2. Separate Control and Data channels............................6
4.3. Reliability...................................................7 4.3. Reliability...................................................7
4.4. Congestion Control............................................8 4.4. Congestion Control............................................8
4.5. Security......................................................8 4.5. Security......................................................8
4.6. Addressing....................................................8 4.6. Addressing....................................................8
4.7. Prioritization................................................8 4.7. Prioritization................................................8
4.8. HA Decisions..................................................8 4.8. HA Decisions..................................................8
4.9. Encapsulations Used...........................................8 4.9. Encapsulations Used...........................................9
5. TML Messaging...................................................8 5. TML Messaging...................................................9
5.1. TML Message Header............................................9 6. TML Interface to Upper layer Protocol...........................9
5.1.1. Version (version)...........................................9 6.1. TML Service Interface........................................10
5.1.2. Upper Layer Protocol Flag (f)...............................9 6.1.1. TML Initialize.............................................10
5.1.3. Message Type (msgType)......................................9 6.1.2. TML Channel Open...........................................11
5.1.4. TML Message Length (tmlMsgLength)...........................9 6.1.3. TML Channel Close..........................................12
5.1.5. TML Message Body...........................................10 6.1.4. TML Channel Write..........................................13
5.2. TML Messages.................................................10 6.1.5. TML Channel Read...........................................14
5.2.1. Channel Close..............................................10 6.1.6. TML Multicast Group Join...................................15
5.2.2. Heartbeat..................................................10
5.2.3. Multicast Group Join Request...............................10
5.2.4. Multicast Group Join Response..............................10
5.2.5. Multicast Group Leave Request..............................11
5.2.6. Multicast Group Leave Response.............................11
6. TML Interface to Upper layer Protocol..........................11
6.1. TML API......................................................11
6.1.1. TML Initialize.............................................11
6.1.2. TML Channel Open...........................................12
6.1.3. TML Channel Close..........................................13
6.1.4. TML Channel Write..........................................14
6.1.5. TML Channel Read...........................................15
6.1.6. TML Multicast Group Join...................................16
6.1.7. TML Multicast Group Leave..................................16 6.1.7. TML Multicast Group Leave..................................16
6.2. Protocol Initialization and Shutdown Model...................17 6.2. Protocol Initialization and Shutdown Model...................17
6.2.1. Protocol Initialization....................................17 6.2.1. Protocol Initialization....................................17
6.2.2. Protocol Shutdown..........................................18 6.2.2. Protocol Shutdown..........................................19
6.3. Multicast Model..............................................20 6.3. Multicast Model..............................................20
6.4. Broadcast Model..............................................22
7. Security Considerations........................................22 7. Security Considerations........................................22
7.1. TLS Usage for this TML.......................................22 7.1. TLS Usage for this TML.......................................23
8. IANA Considerations............................................23 8. IANA Considerations............................................23
9. References.....................................................23 9. Manageability..................................................23
9.1. Normative References.........................................23 10. References....................................................23
9.2. Informative References.......................................23 10.1. Normative References........................................23
10. Acknowledgments...............................................24 10.2. Informative References......................................24
11. Authors' Addresses............................................24 11. Acknowledgments...............................................25
12. Authors' Addresses............................................25
1. Definitions 1. Definitions
The following definitions are taken from [3], [5] The following definitions are taken from [3], [5]
ForCES Protocol - While there may be multiple protocols used within ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" refers the overall ForCES architecture, the term "ForCES protocol" refers
only to the protocol used at the Fp reference point in the ForCES only to the protocol used at the Fp reference point in the ForCES
Framework in RFC3746 [RFC3746]. This protocol does not apply to Framework in RFC3746 [RFC3746]. This protocol does not apply to
CE-to-CE communication, FE-to-FE communication, or to communication CE-to-CE communication, FE-to-FE communication, or to communication
between FE and CE managers. Basically, the ForCES protocol works in between FE and CE managers. Basically, the ForCES protocol works in
a master-slave mode in which FEs are slaves and CEs are masters. a master-slave mode in which FEs are slaves and CEs are masters.
skipping to change at page 5, line 43 skipping to change at page 5, line 33
ordering, etc. are handled. It is expected more than one TML will ordering, etc. are handled. It is expected more than one TML will
be standardized. The different TMLs each could implement things be standardized. The different TMLs each could implement things
differently based on capabilities of underlying media and transport. differently based on capabilities of underlying media and transport.
However, since each TML is standardized, interoperability is However, since each TML is standardized, interoperability is
guaranteed as long as both endpoints support the same TML. All guaranteed as long as both endpoints support the same TML. All
ForCES Protocol Layer implementations should be portable across all ForCES Protocol Layer implementations should be portable across all
TMLs, because all TMLs have the same top edge semantics. TMLs, because all TMLs have the same top edge semantics.
4. TCP/IP TML Overview 4. TCP/IP TML Overview
[TBD: Update this section based on the protocol selected for the
data channel.]
The TCP/IP TML consists of two TCP connections between the CE and FE The TCP/IP TML consists of two TCP connections between the CE and FE
over which the protocol messages are exchanged. One of the over which the protocol messages are exchanged. One of the
connections is called the control channel, over which control connections is called the control channel, over which control
messages are exchanged, the other is called data channel over which messages are exchanged, the other is called data channel over which
external protocol packets, such as routing packets will be external protocol packets, such as routing packets will be
exchanged. The TCP connections will use unique server port numbers exchanged. The TCP connections will use unique server port numbers
for each of the channels. In addition to this, this TML will provide for each of the channels. In addition to this, this TML will provide
mechanisms to prioritize the messages over the different channels. mechanisms to prioritize the messages over the different channels.
Some of the rationale for choosing this transport mechanism as well Some of the rationale for choosing this transport mechanism as well
skipping to change at page 6, line 28 skipping to change at page 6, line 21
4.2.Separate Control and Data channels 4.2.Separate Control and Data channels
The ForCES NEs are subject to Denial of Service (DoS) attacks The ForCES NEs are subject to Denial of Service (DoS) attacks
[Requirements Section 7 #15]. A malicious system in the network can [Requirements Section 7 #15]. A malicious system in the network can
flood a ForCES NE with bogus control packets such as spurious RIP or 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 OSPF packets in an attempt to disrupt the operation of and the
communication between the CEs and FEs. In order to protect against communication between the CEs and FEs. In order to protect against
this situation, the TML uses separate control and data channels for this situation, the TML uses separate control and data channels for
communication between the CEs and FEs. Figure 2 below illustrates communication between the CEs and FEs. Figure 2 below illustrates
the different communication channels between the CEs and the FEs; the different communication channels between the CEs and the FEs. As
the communication channels for support of High Availability with an example, the communication channels for support of High
redundant CEs are also included. Availability with redundant CEs are also included. The setup of
these channels would be dependent on the High Availability model
used in the NE.
ACTIVE CE STANDBY CE ACTIVE CE STANDBY CE
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| CE: PL | | CE: PL | | CE: PL | | CE: PL |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| CE: TML | | CE: TML | | CE: TML | | CE: TML |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| CE: TCP | | CE: TCP | | CE: TCP | | CE: TCP |
+-------------------+ +-------------------+ +-------------------+ +-------------------+
| | | | | | | | | | | | | | | | | | | |
skipping to change at page 8, line 15 skipping to change at page 8, line 13
ordering of data) required for ForCES protocol control messages. ordering of data) required for ForCES protocol control messages.
4.4.Congestion Control 4.4.Congestion Control
TCP provides congestion control needed to satisfy this requirement. TCP provides congestion control needed to satisfy this requirement.
4.5.Security 4.5.Security
This TML uses TLS [8] to provide security in insecure environments. This TML uses TLS [8] to provide security in insecure environments.
Please see section 7 on security considerations for more details. Please see section 7 on security considerations for more details.
[TBD: Update based on IPSec/TLS decision.]
4.6.Addressing 4.6.Addressing
This TML uses addressing provided by IP layer. For unicast This TML uses addressing provided by IP layer. For unicast
addressing/delivery, it uses the TCP connection between the CE and addressing/delivery, it uses the TCP connection between the CE and
FE. For multicast/broadcast addressing/delivery, this TML uses FE for control messaging. For multicast/broadcast
multiple TCP connections between the CE and FEs. addressing/delivery of control messages, this TML uses multiple TCP
connections between the CE and FEs.
Additionally, the TML layer maintains the mapping between the PL
layer addresses and the channel descriptors assigned by the TML
layer. The PL layer is unaware of these descriptors; the PL layer
only uses the PL layer addresses for all communication with the TML
layer.
[TBD: Add any information on addressing for data channel.]
4.7.Prioritization 4.7.Prioritization
This TML provides prioritization of messages sent over control This TML provides prioritization of messages sent over control
channel as compared to the data channel. This has also been found to channel as compared to the data channel. This has also been found to
be useful in face of DoS attacks on the protocol. The details of be useful in face of DoS attacks on the protocol. Additionally it
this are TBD. supports multiple levels of prioritization for control messages. The
scheduling algorithm used at the TML layer gives preferential
treatment to higher priority messages. The scheduling algorithm
used in the TML layer is implementation dependent.
4.8.HA Decisions 4.8.HA Decisions
The TML layer supports heartbeat messages between peer TML layers to The TML layer supports heartbeat messages between peer TML layers to
indicate liveness of the entity generating it. The frequency of the indicate liveness of the entity generating it. The frequency of the
heartbeat message may be specified at protocol initialization time. heartbeat message may be specified at protocol initialization time.
4.9.Encapsulations Used [TBD: Remove this? Use liveliness message at TCP layer? What about
for the data channel? What if the protocol doesnĂt support such a
TML adds its own header on all ForCES protocol messages that it message? If a heartbeat message is required at the TML layer for
receives, and additionally on messages it generates. The ForCES the data channel, does that imply that TML messaging is required?
protocol and TML messages are further encapsulated with a TCP/IP See updates to Section 4.9 and 5.]
header. The format of the TML header is specified in Section 5. TML is responsible for keeping the control and data communication
channels up. It however does not have the authority to decide which
5. TML Messaging CE to set up the channels with. That is outside its control.
TML adds on a TML header to all messages that it either receives
from the PL layer or those messages that it generates. The TML
header is followed by the message body. The message body may
comprise a PL message or it may be a message generated by the TML
layer for communicating with its peer. A flag in the TML header
specifies whether the message is associated with the PL layer. The
next section details the TML header.
5.1.TML Message Header
Figure 3 below shows the format of the TCP TML message header.
NOTE: The header may undergo some modifications in the next revision
of this draft.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version|reserved |f| msgType | tmlMsgLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD: message body |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: TCP TML Message Header Format
5.1.1.Version (version)
The version field (4 bits) specifies the version of the TML layer
protocol supported by the implementation. An entity implementing
the TML layer protocol should be backward compatible with previous
versions of the protocol.
5.1.2.Upper Layer Protocol Flag (f)
The upper layer protocol flag (1 bit) specifies if the TML layer is
carrying a message sent by the PL Layer. If the protocol flag is
set, the message body comprises of a PL message which is not
interpreted by the peer TML layer; the rest of the TML header and
message is ignored by the peer TML layer. If the protocol flag is
not set, the message body carries a TML message; hence, the rest of
the TML header needs to be read by the peer TML layer and the
message body appropriately processed.
5.1.3.Message Type (msgType)
The message type (6 bits) field is applicable only if the protocol
flag field is not set. It specifies the TML message being sent
between peer TML layers.
5.1.4.TML Message Length (tmlMsgLength)
The TML message length field is applicable only if the protocol flag
field is not set. It specifies the length of the TML message in
octets inclusive of the TML header.
5.1.5.TML Message Body
Format of this is TBD.
5.2.TML Messages
5.2.1.Channel Close
The channel close message is generated by the TML layer in response
to a request to close a specified channel. This message is sent to
the peer TML layer to notify it of the closure. This provides
information to the peer TML layer so it can either close its end of
the channel also or drop any messages received by the upper layer
protocol.
ForCES protocol usage: This message may be sent from either the CE
or the FE TML layer depending on which entity initiated the close.
5.2.2.Heartbeat
A heartbeat message is exchanged between peer TML layers to
communicate liveness of the entity generating the message.
ForCES protocol usage: This message may be sent from either the CE
to an FE or vice-versa.
5.2.3.Multicast Group Join Request
The multicast group join request message is triggered by a request
from the PL layer to join a specific multicast group. The peer TML
layer on receiving this request creates the specified multicast
group if it didnĂt previously exist. It updates the membership of
the group to include the entity requesting the join.
ForCES protocol usage: Since only FEs may be the leaves in a
multicast group, this message is sent by the FE TML to the CE TML,
due to a join request from the FE PL.
5.2.4.Multicast Group Join Response
The multicast group join response message is generated by the TML If a FE-CE communication channel goes down or connectivity is lost,
Layer in response to a join request message. the following steps are taken by the TML layer:
- FE TML attempts to reestablish the communication channel
- If the FE TML is unable to reestablish the channel (after some
configured number of retries/timeout), it notifies the FE PL that
the channel is down.
- CE TML waits for the channel to be reestablished (since only the
FE can reestablish it) for some configured timeout prior to
notifying the CE PL that the channel is down.
ForCES protocol usage: If only FEs may be the leaves in a multicast TBD: Since the PL layer is unaware of the number of channels etc.,
group, this message is generated by the CE TML and sent to the FE what if only one channel goes down, but the other is up? The TML
TML, in response to the join request message received from the FE layer notifies the PL layer of which channel (control/data) is down?
TML.
5.2.5.Multicast Group Leave Request If an FE goes down and a standby FE exists for it, and it has
communication channels set up with the CE, the CE PL may start to
use the channels associated with the standby FE. This is not within
the scope of TML itself, but falls in the scope of High
Availability.
The multicast group leave request message is triggered by a request TBD: If an FE goes down and a standby FE exists for it, but it does
from the PL layer to leave a specific multicast group. The peer TML not have communication channels set up with the CE, how should it be
layer on receiving this request removes the specified multicast notified to set up the channels? This is not within the scope of
group if the entity requesting to leave is the only member of the TML itself, but falls in the scope of High Availability. Do we need
group. Else, it updates the membership of the group to exclude the this mentioned here?
entity requesting the leave.
ForCES protocol usage: If only FEs may be the leaves in a multicast 4.9.Encapsulations Used
group, this message is sent by the FE TML to the CE TML, due to a
leave request from the FE PL.
5.2.6.Multicast Group Leave Response There is no further message encapsulation of control and data
messages done at the TML layer. The PL generated control messages
are transported as is by the TML layer. The ForCES protocol control
messages are encapsulated with a TCP/IP header. [TBD: Encapsulation
of data messages is dependent on the protocol that will be used for
the data channel (TCP is only for the control channel). If DCCP is
used for the data channel, then a DCCP header will be added.]
The multicast group leave response message is generated by the TML 5. TML Messaging
Layer in response to a leave request message.
ForCES protocol usage: If only FEs may be the leaves in a multicast There is no TML layer messaging. TML only transports messages from
group, this message is generated by the CE TML and sent to the FE the PL layer.
TML, in response to the leave request message received from the FE
TML.
6. TML Interface to Upper layer Protocol 6. TML Interface to Upper layer Protocol
ForCES TML interfaces with an upper layer protocol, the PL Layer and ForCES TML interfaces with an upper layer protocol, the PL Layer and
a lower layer protocol, TCP (in the case of TCP TML). This section a lower layer protocol, TCP (in the case of TCP TML). This section
defines the interface to the upper layer protocol. This interface defines the interface to the upper layer protocol. This interface
should be used only as a guideline in implementing the API. should be used only as a guideline in implementing the API.
Additionally, although the current interface is defined mainly as a Additionally, although the current interface is defined mainly as a
synchronous interface, the interface may be implemented to be synchronous interface, the interface may be implemented to be
asynchronous if desired. asynchronous if desired.
6.1.TML API 6.1.TML Service Interface
6.1.1.TML Initialize 6.1.1.TML Initialize
status tmlInit( status tmlInit(
in channelType, in channelType,
in initAttributes) in initAttributes)
Input Parameters: Input Parameters:
channelType: control versus data channel channelType: control versus data channel
initAttributes: initialization parameters initAttributes: initialization parameters
skipping to change at page 12, line 25 skipping to change at page 10, line 48
In the case of ForCES which follows a client-server model, this API In the case of ForCES which follows a client-server model, this API
would be invoked on the CE, which functions as the server. It is would be invoked on the CE, which functions as the server. It is
invoked once for every class of TML channels on a per channel type invoked once for every class of TML channels on a per channel type
basis (control channel versus data channel). For example, say for basis (control channel versus data channel). For example, say for
control messaging, the CE communicates with five FEs using TCP TML control messaging, the CE communicates with five FEs using TCP TML
and with another two FEs, using UDP TML. tmlInit() will need to be and with another two FEs, using UDP TML. tmlInit() will need to be
invoked twice, once for the TCP TML attributes and once for the UDP invoked twice, once for the TCP TML attributes and once for the UDP
TML attributes for the control channel setup with all of the FEs. TML attributes for the control channel setup with all of the FEs.
The same holds true for the data channel setup in the above case. The same holds true for the data channel setup in the above case.
[TBD: TBD: Should tmlInit() be invoked by the PL Layer at all since
we have now said the PL Layer is oblivious of the number of
channels, their attributes etc. Currently, we had specified that
tmlInit() would specify the attributes for the channels to be setup.
It seems like due to the change in the connection setup model this
information should be fed to the TML Layer via some other means.
The CE functions as the server, so the server should be up and
running however prior to the clients (FEs) coming up and trying to
connect to the server (CE). The other option is that the mechanism
to specify attributes for the channels is distinct from the process
that uses those attributes to start up the server. In that case,
tmlInit() could be used mainly to start the server.]
6.1.2.TML Channel Open 6.1.2.TML Channel Open
status tmlOpen( status tmlOpen(
in channelType,
in elementId, in elementId,
in channelMode, in channelMode,
in channelAttributes, in ctrlChannelAttributes,
in eventHandlerCallBack, in dataChannelAttributes,
out channelDescriptor) in eventHandlerCallBack)
Input Parameters: Input Parameters:
channelType: control channel or data channel
elementId: Specific CE for which channel needs to be setup elementId: Specific CE for which channel needs to be setup
channelMode: unicast versus multicast channelMode: unicast versus multicast
channelAttributes: channel establishment parameters ctrlChannelAttributes: control channel establishment parameters
dataChannelAttributes: data channel establishment parameters
eventHandlerCallback: Callback function to be invoked on event eventHandlerCallback: Callback function to be invoked on event
generation generation
Output Parameters: Output Parameters:
channelDescriptor: handle to communication channel none
Returns: Returns:
status: SUCCESS status: SUCCESS
Errors TBD Errors TBD
Synopsis: Synopsis:
tmlOpen() results in a communication channel of type channelType tmlOpen() results in one or more communication channels for control
(control versus data), being established with the specified and data messaging being established with the specified elementId.
elementId. The channel may be specified as unicast or multicast via It is up to the TML layer implementation whether to setup a single
channel for both control and data messaging or distinct channels for
each. The channel may be specified as unicast or multicast via
channelMode. This call may either trigger the establishment of the channelMode. This call may either trigger the establishment of the
channel, or if the channel is already established, it only results channel(s), or if the channel(s) are already established, it only
in a registration for that channel. In either case, if successful, results in a registration for the channel(s). In either case, if
a handle to the open channel is returned via a channelDescriptor. successful, status is returned to indicate successful
If this call triggers the establishment of the channel, the channel creation/registration of the control and data channels. No
is established using the channelAttributes parameter specified to descriptors are returned to the PL layer since the TML layer
the call. Once the channel is setup (or if already setup prior to maintains the mapping between the PL provided elementId and the
this call), the caller of this API is also capable of receiving TML descriptors it allocates. If this call triggers the establishment of
events via the specified event handling callback function. If this the control and data channels, the channels are established using
call is invoked multiple times on a channel that has already been the ctrlChannelAttributes and dataChannelAttributes parameters
opened and registered, a return status of ALREADY_REGISTERED is respectively, specified to the call. Once the channel(s) are setup
returned, with no change to registration. (or if already setup prior to this call), the caller of this API is
also capable of receiving TML events via the specified event
handling callback function. If this call is invoked multiple times
on a channel that has already been opened and registered, a return
status of ALREADY_REGISTERED is returned, with no change to
registration.
ForCES Usage Model: ForCES Usage Model:
In the case of ForCES which follows a client-server model, this API In the case of ForCES which follows a client-server model, this API
would be invoked on the FE by FE PL, which functions as the client. would be invoked on the FE by FE PL, which functions as the client.
On each FE, it is invoked once per channel that the FE wishes to On each FE, it is invoked once for both control and data channels
setup with the CE. that the FE wishes to setup with the CE.
Notes: Notes:
In the case of TCP TML, since there is no inherent support for In the case of TCP TML, since there is no inherent support for
multicast, regardless of the channelMode specified, the specified multicast, regardless of the channelMode specified, the specified
channel would be setup as a unicast channel; however, the unicast channel would be setup as a unicast channel; however, the unicast
channel would be able to support pseudo multicast. Hence, there is channel would be able to support pseudo multicast. Hence, TCP TML
no need to set up a distinct channel for unicast and a distinct has no need to set up distinct channels for unicast and multicast
channel for multicast in the case of TCP TML (as may be the case for communication; they are both mapped to the same TCP connection.
UDP TML).
6.1.3. TML Channel Close 6.1.3. TML Channel Close
status tmlClose( status tmlClose(
in channelDescriptor in elementId,
in mode) in mode)
Input Parameters: Input Parameters:
channelDescriptor: handle to communication channel to be elementId: address of element with which communication channel is
terminated to be terminated
mode: mode of operation for the close ű forced versus controlled mode: mode of operation for the close ű forced versus controlled
Output Parameters: Output Parameters:
none none
Returns: Returns:
status: SUCCESS status: SUCCESS
Errors TBD Errors TBD
Synopsis: Synopsis:
Tears down/terminates specified communication channel. No further Tears down/terminates communication channels connecting to the
CE PL ű FE PL messaging is possible after this. If the mode is specified elementId. This API closes both control and data channels
specified as controlled, current messages that are pending in the (regardless of whether they are implemented as a single channel or
TML layer shall be sent, but no new messages shall be accepted by distinct channels in the TML layer); it is not possible to close
the TML layer on this channel. In the forced model, messages just one of them. No further CE PL ű FE PL messaging is possible
pending in the TML layer shall be discarded. Since the channel was after this. If the mode is specified as controlled, current
terminated, a subsequent tmlOpen() will trigger establishment of the messages that are pending in the TML layer shall be sent, but no new
channel. messages shall be accepted by the TML layer on this channel. In the
forced mode, messages pending in the TML layer shall be discarded.
Since the channel was terminated, a subsequent tmlOpen() will
trigger establishment of the channel.
ForCES Usage Model: ForCES Usage Model:
This API may be invoked by either the CE or the FE. If the FE PL This API may be invoked by either the CE or the FE. If the FE PL
invokes it, the FE TML sends a message to the CE TML informing it invokes it, it specifies a CE ID for the elementId. If the CE PL
that the channel has been shutdown, which results in an upcall to invokes it, it specifies an FE ID for the elementId.
the CE PL. This will result in the CE PL also shutting down its end
of the channel.
6.1.4.TML Channel Write 6.1.4.TML Channel Write
status tmlWrite( status tmlWrite(
in channelDescriptor, in elementId,
in msgType,
in msg, in msg,
in msgSize, in msgSize,
in timeout, in timeout,
out bytesWritten) out bytesWritten)
Input Parameters: Input Parameters:
channelDescriptor: handle to communication channel to be written elementId: address of element to be written to; may be a unicast,
to multicast or broadcast address
msgType: control versus data message
msg: message to be sent msg: message to be sent
msgSize: size of message to be sent msgSize: size of message to be sent
timeout: specifies blocking or non-blocking write. Value of -1 timeout: specifies blocking or non-blocking write. Value of -1
implies blocking write (wait forever), value of 0 implies non- implies blocking write (wait forever), value of 0 implies non-
blocking write blocking write
Output Parameters: Output Parameters:
bytesWritten: number of bytes actually transmitted bytesWritten: number of bytes actually transmitted
Returns: Returns:
status: SUCCESS status: SUCCESS
Errors TBD Errors TBD
Synopsis: Synopsis:
Sends message to the address specified by elementId. If the
Sends message over the specified channel. If the specified specified elementId is associated with a multicast group, the
channelDescriptor is associated with a multicast group, the message message will be sent to all members of the group. Similarly, if the
will be sent to all members of the group. This does not imply that elementId specified is a broadcast address, the message is sent to
the message has actually been transmitted. The message is queued in all elements associated with the broadcast address. The msgType
the appropriate queue for transmission. Once this call returns, the parameter is used to specify whether the message is a control or
message buffer may be freed. If TMLĂs message queues are full, the data type of message. Based on the message type, the TML will send
timeout will be used to determine how long to wait prior to the message over the appropriate channel. The TML layer uses the
returning; if the specified timeout expires, and no message buffer address specified by elementId and the msgType to map to the
becomes available, the API returns with an error. appropriate channel to be used for sending the message. The message
is queued in the appropriate queue for transmission. Once this call
returns, the message buffer may be freed. If TMLĂs message queues
are full, the timeout will be used to determine how long to wait
prior to returning; if the specified timeout expires, and no message
buffer becomes available, the API returns with an error.
ForCES Usage Model: ForCES Usage Model:
This API may be invoked by either the FE PL or the CE PL. This API may be invoked by either the FE PL or the CE PL. If the FE
PL invokes it, it specifies a CE ID for the elementId. If the CE PL
invokes it, it specifies an (unicast/multicast/broadcast) FE ID for
the elementId.
In the case of TCP TML since there is a single channel used for
unicast, multicast and broadcast messaging, the same channel is used
for sending messages regardless of the address specified. In other
cases where there are distinct channels for unicast versus
multicast, the channel to be written to will differ based on the
address specified.
6.1.5.TML Channel Read 6.1.5.TML Channel Read
status tmlRead( status tmlRead(
in channelDescriptor, in elementId,
in msgType,
in msgBuf, in msgBuf,
in timeout, in timeout,
out bytesRead) out bytesRead)
Input Parameters: Input Parameters:
channelDescriptor: handle to communication channel to be read from elementId: address of element to be read from; may be a unicast,
multicast or broadcast address
msgType: control versus data message
msgBuf: buffer into which message is to be read msgBuf: buffer into which message is to be read
timeout: specifies blocking or non-blocking read. Value of -1 timeout: specifies blocking or non-blocking read. Value of -1
implies blocking read (wait forever), value of 0 implies non- implies blocking read (wait forever), value of 0 implies non-
blocking read blocking read
Output Parameters: Output Parameters:
bytesRead: number of bytes actually read bytesRead: number of bytes actually read
Returns: Returns:
status: SUCCESS status: SUCCESS
skipping to change at page 15, line 39 skipping to change at page 15, line 4
timeout: specifies blocking or non-blocking read. Value of -1 timeout: specifies blocking or non-blocking read. Value of -1
implies blocking read (wait forever), value of 0 implies non- implies blocking read (wait forever), value of 0 implies non-
blocking read blocking read
Output Parameters: Output Parameters:
bytesRead: number of bytes actually read bytesRead: number of bytes actually read
Returns: Returns:
status: SUCCESS status: SUCCESS
Errors TBD Errors TBD
Synopsis: Synopsis:
Reads message on the specified channel. Once the message is copied Reads message from the specified address. The msgType parameter is
into msgBuf specified by the call, the TML message buffer may be used to specify whether the message to be read is a control or data
freed. If TMLĂs message queues are empty (no message is available), type of message. The TML layer uses the address specified by
the timeout will be used to determine how long to wait prior to elementId and the msgType to map to the appropriate channel to be
used for reading the message. Once the message is copied into
msgBuf specified by the call, the TML message buffer may be freed.
If TMLĂs message queues are empty (no message is available), the
timeout will be used to determine how long to wait prior to
returning; if the specified timeout expires, and no message becomes returning; if the specified timeout expires, and no message becomes
available, the API returns with an error. available, the API returns with an error.
If a non-blocking read is executed, the caller of the API is If a non-blocking read is executed, the caller of the API is
notified via an upcall when a message becomes available. notified via an upcall when a message becomes available.
TBD: If the channelDescriptor specified is associated with a
multicast group, it should be considered invalid since multicast is ForCES Usage Model:
only supported on a write; a read is always associated with reading This API may be invoked by either the CE or the FE. If the FE PL
from a single channel. invokes it, it specifies a CE ID for the elementId. If the CE PL
invokes it, it specifies an (unicast/multicast/broadcast) FE ID for
the elementId.
In the case of TCP TML since there is a single channel used for
unicast, multicast and broadcast messaging, the same channel is used
for reading messages regardless of the address specified. In other
cases where there are distinct channels for unicast versus
multicast, the channel to be read from will differ based on the
address specified.
6.1.6.TML Multicast Group Join 6.1.6.TML Multicast Group Join
status tmlMulticastGroupJoin( status tmlMulticastGroupJoin(
in groupId,
in groupAttributes) in groupAttributes)
Input Parameters: Input Parameters:
groupAttributes: Attributes associated with the multicast group to groupId: address of multicast group to join
groupAttributes: attributes associated with the multicast group to
be joined be joined
Output Parameters: Output Parameters:
none none
Returns: Returns:
status: SUCCESS status: SUCCESS
Errors TBD Errors TBD
Synopsis: Synopsis:
Joins the specified multicast group as leaf node in the group. If
this is the first join request being received for this group, it Joins the multicast group specified by groupId as leaf node in the
results in the creation of the group and the allocation of a group. Once a member of this group, the entity calling this API will
groupDescriptor (which is equivalent to a channelDescriptor). Once a be capable of receiving messages addressed to this multicast group.
member of this group, the entity calling this API will be capable of The TML layer on each end (CE/FE) maintains the mapping between the
receiving messages addressed to this multicast group. PL layer multicast address and the descriptors. The TML layer on
the element which is the root of the multicast updates the set of
elements that are members of the group specified by groupId.
ForCES Usage Model: ForCES Usage Model:
If the intent is that only FEs can be members of a multicast group This API would be invoked on both the CE and the FE. Initially, the
and only a CE can be the source of a multicast, this API would be intent is to only support FE multicast. In such a case. on the FE
invoked on the FE that wishes to join a multicast group. the API is invoked once the PL layer on the FE receives a request
from the PL layer on the CE to join a specified multicast group. On
the CE it is invoked after the FE has successfully joined the
multicast group.
6.1.7.TML Multicast Group Leave 6.1.7.TML Multicast Group Leave
status tmlMulticastGroupLeave( status tmlMulticastGroupLeave(
in groupAttributes) in groupId)
Input Parameters: Input Parameters:
groupAttributes: Attributes associated with the multicast group to groupId: address of multicast group to leave
leave
Output Parameters: Output Parameters:
none none
Returns: Returns:
status: SUCCESS status: SUCCESS
Errors TBD Errors TBD
Synopsis: Synopsis:
Leaves the specified multicast group it had previously joined. Once Leaves the multicast group specified by groupId it had previously
an entity is not a member of the multicast group, it is no longer joined. Once an entity is not a member of the multicast group, it is
capable of receiving messages addressed to group. If this leave no longer capable of receiving messages addressed to group. The
request is associated with the only member of the group, the TML layer on each end (CE/FE) updates the mapping between the PL
multicast group is removed, and its associated groupDescriptor layer multicast address and the descriptors. The TML layer on the
invalidated. element which is the root of the multicast updates the set of
elements that are members of the group specified by groupId.
ForCES Usage Model: ForCES Usage Model:
If the intention is that only FEs can be members of a multicast This API would be invoked on both the CE and the FE. Initially, the
group and only a CE can be the source of a multicast, this API would intent is to only support FE multicast. In such a case, on the FE
be invoked on the FE that wishes to leave a group it had previously the API is invoked once the PL layer on the FE receives a request
joined. from the PL layer on the CE to leave a specified multicast group. On
the CE it is invoked after the FE has successfully left the
multicast group.
6.2.Protocol Initialization and Shutdown Model 6.2.Protocol Initialization and Shutdown Model
In order for the peer PL Layers to communicate, the control and data In order for the peer PL Layers to communicate, the control and data
channels must be setup. This section defines a model for the setup channels must be setup. This section defines a model for the setup
of the channels, using the TML interface defined above. In this of the channels, using the TML interface defined above. In this
model, the peer TML Layers may establish the control and data model, the peer TML Layers may establish the control and data
channels between the FE and the CE without the involvement of the PL channels between the FE and the CE without the involvement of the PL
Layers, or if desired, the PL Layer may trigger the setup of the Layers, or if desired, the PL Layer may trigger the setup of the
channels; this is left as an implementation decision. Both modes channels; this is left as an implementation decision. Both modes
may also be supported within an implementation. may also be supported within an implementation.
6.2.1.Protocol Initialization 6.2.1.Protocol Initialization
The control channel must be established between the FE TML and the The control channel must be established between the FE TML and the
CE TML for establishment of association to proceed. This channel CE TML for establishment of association to proceed. This channel
will be used for messages related to the association setup and will be used for messages related to the association setup and
capability query. The data channel must be established no later capability query. The data channel must be established no later
than the response from the FE to the CE Topology query message. than the response from the FE to the CE Topology query message. The
following are the significant aspects associated with channel setup:
- A single call by the PL layer sets up the communication channels
for both control and data messaging to a specific FE. The call
specifies Unicast CE Id and attributes for control and data
channels.
- It is up to the TML layer whether to set up a single channel for
both control and data or distinct channels for control and data
- TML sets up the appropriate channels and allocates required
descriptors for the channels. TML layer maintains a mapping
between the Unicast FE/CE Id and the channel descriptors and
channel type (control versus data) it creates.
- There is no need for channel descriptors to be returned to the PL
layer at either the FE or the CE. PL Layer only uses the Unicast
FE/CE Id for read/write calls and specifies the type of message
(control versus data) to be read/written.
- If only one of the channels is setup successfully, the TML layer
will have to return appropriate status that specifies which
channel is setup successfully and which isnĂt.
Figure 4 illustrates the initialization model where the PL layer via Figure 4 illustrates the initialization model where the PL layer via
an interface provided by the TML Layer, triggers the setup of the an interface provided by the TML Layer, triggers the setup of the
control and data channels. control and data channels.
FE PL FE TML CE TML CE PL FE1 PL FE1 TML CE TML CE PL
| | | | \ | | | | \
/ | | | tmlInit(Cc) | | / | | | TBD:tmlInit() | |
FE | | | |<--------------| > CE Init/ FE | | | |<--------------| > CE Init/
Init/ < | | | tmlInit(Cd) | | Bootup Init/ < | | | | | Bootup
Bootup | | | |<--------------| / Bootup | | | | | /
\ | | | | \ | | | |
| tmlOpen(Cc) | | | | tmlOpen(CeId) | | |
|-------------->| | | \
| |TCP CtrlChan(Cc) Setup | | |
| |~~~~~~~~~~~~~~~~~~~~~~>| | | Setup control
| |CtrlChann(Cc) Setup Rsp| | > channel if not
| |<~~~~~~~~~~~~~~~~~~~~~~| | | already
| <-- CcDes | | | | setup
|tmlEvent(CcUp) | |tmlEvent(CcUp) | /
|<--.--.--.--.--| |--.--.--.--.-->|
| | | CcDes |
| tmlOpen(Cd) | | |
|-------------->| | | \ |-------------->| | | \
| |TCP DataChann(Cd) Setup| | | Setup data | |CtrlChan(Cc) Setup | | | Setup control
| |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not | |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not
| |DataChann(Cd) Setup Rsp| | > channel if not | | FeId . [CcDes<ctrl>] | | setup. TML
| |<~~~~~~~~~~~~~~~~~~~~~~| | | already | | | | > has mapping
| <-- CdDes | | | | setup | |CtrlChan(Cc) Setup Rsp | | | from PL Layer
|tmlEvent(CdUp) | |tmlEvent(CdUp) | / | |<~~~~~~~~~~~~~~~~~~~~~~| | | Id to channel
| CeId . [CcDes<ctrl>] | | | descriptor and
| | | / channel type.
| | | |
| |DataChan(Cd) Setup | | | Setup data
| |~~~~~~~~~~~~~~~~~~~~~~>| | | channel if not
| | FeId . [CcDes<ctrl>, | | setup. TML
| | CdDes<data>] | | updates
| | | | > mapping from
| |DataChan(Cd) Setup Rsp | | | PL Layer
| |<~~~~~~~~~~~~~~~~~~~~~~| | | Id to channel
| CeId . [CdDes<data>] | | | descriptor and
| | | | / channel type.
| | | |
| <-- status | | |
| | | |
|tmlEvent(ChUp) | |tmlEvent(ChUp) |
|<--.--.--.--.--| |--.--.--.--.-->| |<--.--.--.--.--| |--.--.--.--.-->|
| | | CdDes | | | | |
| | Asso Setup Req | | | | Asso Setup Req | |
|---------------|-----------------------|-------------->| |---------------|-----------------------|-------------->|
| | Asso Setup Rsp | | | | Asso Setup Rsp | |
|<--------------|-----------------------|---------------| |<--------------|-----------------------|---------------|
| | | | | | | |
| | Capability Query | | | | Capability Query | |
|<--------------|-----------------------|---------------| |<--------------|-----------------------|---------------|
| | Capability Query Rsp | | | | Capability Query Rsp | |
|---------------|-----------------------|-------------->| |---------------|-----------------------|-------------->|
| | | | | | | |
skipping to change at page 18, line 38 skipping to change at page 18, line 47
|---------------|-----------------------|-------------->| |---------------|-----------------------|-------------->|
| | | | | | | |
| | Topology Query | | | | Topology Query | |
|<--------------|-----------------------|---------------| |<--------------|-----------------------|---------------|
| | Topology Query Rsp | | | | Topology Query Rsp | |
|---------------|-----------------------|-------------->| |---------------|-----------------------|-------------->|
| | | | | | | |
| |STEADY STATE OPERATION | | | |STEADY STATE OPERATION | |
|<--------------|-----------------------|-------------->| |<--------------|-----------------------|-------------->|
| | | | | | | |
Legend: Legend:
PL --------> PL : Protocol layer messaging PL --------> PL : Protocol layer messaging
PL --------> TML: TML API PL --------> TML: TML API
TML ========> TML: Messaging between TML Layers
TML --.--.--> PL : Events/Notifications/Upcalls TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication TML ~~~~~~~~> TML: Internal protocol communication
Figure 4: Protocol Initialization (Channel Setup) Figure 4: Protocol Initialization (Channel Setup)
6.2.2.Protocol Shutdown 6.2.2.Protocol Shutdown
The control channel teardown must occur only after the association The control channel teardown must occur only after the association
teardown has occurred. The data channel teardown may occur no earlier teardown has occurred. The data channel teardown may occur no earlier
than the association teardown. than the association teardown.
The PL Layer may completely shutdown a channel via invocation of the The PL Layer may shutdown control and data channels via invocation of
tmlClose() API. When the PL layer shuts down a channel, the channel is the tmlClose() API. When the PL layer shuts down the channels, the
torn down; hence ForCES messaging between the CE and FE is no longer channels are torn down; hence ForCES messaging between the CE and FE is
possible over that channel. A subsequent tmlOpen() triggers no longer possible over those channels. A tmlClose() results in both
establishment of the channel. This scenario is illustrated in Figure control and data channels (regardless of whether they are implemented
5. as a single channel or distinct channels in the TML layer) being
shutdown; it is not possible to close just one of them. A subsequent
tmlOpen() triggers establishment of the channel. The channel(s) may be
shutdown by either the FE or the CE. If an FE initiates the shutdown,
it specifies the CE Id associated with the channel(s) to be shutdown.
If a CE initiates the shutdown, it specifies the FE Id associated with
the channel(s) to be shutdown. A channel shutdown by the FE is
illustrated in Figure 5 and a channel shutdown by the CE is illustrated
in Figure 6.
FE PL FE TML CE TML CE PL FE PL FE TML CE TML CE PL
| | | | | | | |
| |STEADY STATE OPERATION | | | |STEADY STATE OPERATION | |
|<--------------|-----------------------|-------------->| |<--------------|-----------------------|-------------->|
| | Config Request | | | | Config Request | |
|<--------------|-----------------------|---------------| |<--------------|-----------------------|---------------|
| | Config Response | | | | Config Response | |
|---------------|-----------------------|-------------->| |---------------|-----------------------|-------------->|
| | | | | | | |
| | Association Teardown | | | | Association Teardown | |
|<--------------|-----------------------|---------------| |<--------------|-----------------------|---------------|
| | | | | | | |
| | | | \
|tmlClose(CeId) | | | | FE initiated:
|-------------->| | | > FE specifies CE
| <-- status | | | | Id associated
| | | | / with channel.
Legend:
PL --------> PL : Protocol layer messaging
PL --------> TML: TML API
TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication
Figure 5: Protocol Shutdown: FE Initiated
FE PL FE TML CE TML CE PL
| | | | | | | |
|tmlClose(CdDes)| | | \ | |STEADY STATE OPERATION | |
|-------------->| | | | Data Channel |<--------------|-----------------------|-------------->|
| |DataChan(Cd) Close | | | teardown; it no | | Config Request | |
| |======================>| | > longer exists. |<--------------|-----------------------|---------------|
|<-- Cd Close OK| |tmlCloseUpcall | | PL Layer can no | | Config Response | |
| | |--.--.--.--.-->| | longer use Cd; |---------------|-----------------------|-------------->|
| | | | | TML msging also
| | | | / not possible.
| | | | | | | |
|tmlClose(CcDes)| | | \ | | Association Teardown | |
|-------------->| | | | Control Channel |<--------------|-----------------------|---------------|
| |CtrlChan(Cc) Close | | | teardown; it no
| |======================>| | > longer exists.
|<-- Cc Close OK| |tmlCloseUpcall | | PL Layer can no
| | |--.--.--.--.-->| | longer use Cc;
| | | | | TML msging also
| | | | / not possible.
~ ~ ~ ~
~ ~ ~ ~
| | | | | | | |
| tmlOpen(Cc) | | | \ | | | | \
|-------------->| | | | Subsequent open | | |tmlClose(FeId) | | CE initiated:
| |TCP CtrlChan(Cc) Setup | | | needs to launch | | |<--------------| > FE specifies CE
| |~~~~~~~~~~~~~~~~~~~~~~>| | > setup of the | <-- status | | status --> | | Id associated
| |CtrlChann(Cc) Setup Rsp| | | channel since | | | | / with channel.
| |<~~~~~~~~~~~~~~~~~~~~~~| | | shutdown had
| <-- CcDes | | | | torn the
|tmlEvent(CcUp) | |tmlEvent(CcUp) | | channel down
|<--.--.--.--.--| |--.--.--.--.-->| /
| | | CcDes |
Legend: Legend:
PL --------> PL : Protocol layer messaging PL --------> PL : Protocol layer messaging
PL --------> TML: TML API PL --------> TML: TML API
TML ========> TML: Messaging between TML Layers
TML --.--.--> PL : Events/Notifications/Upcalls TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication TML ~~~~~~~~> TML: Internal protocol communication
Figure 5: Protocol Shutdown Figure 6: Protocol Shutdown: CE Initiated
6.3.Multicast Model 6.3.Multicast Model
The TML layer provides support for multicast. In the ForCES model, The TML layer provides support for multicast. In the ForCES model,
support is required to multicast to the FEs from a CE; in this case, support is required to multicast to the FEs from a CE; in this case,
the CE is the source or root of the multicast and the FEs are the the CE is the source or root of the multicast and the FEs are the
leaves. leaves.
Support for multicast requires that a channel for supporting Support for multicast requires that a channel for supporting
multicast be opened between an FE and the CE. In the case of TCP multicast be opened between an FE and the CE. In the case of TCP
TML, the same channel is used for both unicast and multicast TML, the same channel is used for both unicast and multicast
messaging since multicast mode is simulated using unicast channels messaging since multicast mode is simulated using unicast channels
in this case. Once the channel is open, FEs may join and leave in this case. Once the channel is open, a CE may request FEs to join
specified multicast groups. The first ˘multicast group join÷ and leave specified multicast groups. Multicast support is CE-
request from an FE to a CE for a specific multicast group results in initiated. FEs can join a multicast group only if the CE requests
the creation of the group and an allocation of a group descriptor them to join the group. TML maintains mapping between PL layer IDs
(which is similar to a channel descriptor) for the group. The and channel descriptors for multicast. The following is the
˘multicast group leave÷ request from an FE to the CE on a multicast significant steps for adding or removing members from a multicast
group with just that one member results in the group being removed group:
and the descriptor deallocated. A tmlWrite() on a unicast channel
descriptor results in a unicast message being sent to the FE - CE PL communicates with FE PL for requesting the FE to join or
associated with the channel. A tmlWrite() on a group descriptor leave a multicast group.
results in multicast messaging. Figure 6 illustrates a multicast - FE PL informs FE TML regarding the join or leave request.
scenario with 2 FEs, FE1 and FE2. In the first case, FE1 joins a - FE TML updates the multicast group information. It updates the
multicast group. In the second case, FE2 joins the same multicast mapping between the FE Multicast Id and the channel descriptor to
group, and leaves the group some time later. be used for multicast for that FE. This mapping may be from
[Multicast FE Id] . [FE Id] . [Channel descriptor] or directly
from [Multicast FE Id] . [Channel descriptor]. This is
implementation dependent.
- FE PL responds to CE PL informing it of the status of the join or
leave request.
- If the join or leave request was successful, CE PL informs CETML
regarding the update to the multicast group membership.
- CE TML updates the multicast group membership. It updates the
mapping between the FE Multicast Id and the set of channel
descriptors to be used for multicast to the FEs that are members
of this group. This mapping may be from [Multicast FE Id] . [Set
of FE Ids] . [Set of channel descriptors] or directly from
[Multicast FE Id] . [Set of channel descriptors]. This is
implementation dependent.
- There is no need for any descriptors to be returned to the PL
layer at either the FE or the CE. PL Layer only uses the
Multicast FE Id for write calls and specifies the type of message
(control versus data) to be written.
A tmlWrite() on a unicast FE Id results in a unicast message being
sent to the FE associated with the channel. A tmlWrite() on a
multicast FE Id results in multicast messaging. Figures 7 and 8
illustrate multicast scenarios with 2 FEs, FE1 and FE2. In Figure
7, the CE requests FE1 to join a multicast group. Although not
shown as a separate figure, if FE2 were to join the same group, the
join procedure would be the same as in Figure 7; it would result in
the multicast group membership being updated at the TML layer on the
CE to include FE2 in the group. In Figure 8, the CE requests FE1 to
leave the multicast group, thus resulting in only FE2 being a member
of the multicast group.
Multicast Scenario with FE1 joining group: New group created
Multicast Scenario with FE1:
FE1 PL FE1 TML CE TML CE PL FE1 PL FE1 TML CE TML CE PL
| | | | | | | |
| |STEADY STATE OPERATION | | \ Channel for | | | | \
|<--------------|-----------------------|-------------->| > multicast msgs | MC Grp Join Req (McId) | |
| | | | | already exists |<--------------|-------------------|---------------| | CE:PL Level multicast group
| | | | / via tmlOpen() [TML | tmlJoin(McId) | | | | join request sent to each
~ ~ ~ ~ updates |-------------->| | | | FE:PL that needs to be part
~ ~ ~ ~ MC grp | McId = {FE1_ChDes} | | > of a multicast group, McId,
|tmlMcstGrpJoin | | | \ info] | | | | | where McId specifies a
|-------------->| | | | FE1 joins | <-- status | | | | multicast group Id at the
| |Mcst Group Join Req | | | Multicast st | |======================>| | > Group. 1 join | | | | | PL layer.
| | |tmlJoinUpcall | | request for | MC Grp Join Rsp (status) | |
| | |--.--.--.--.-->| | group, hence |---------------|-------------------|-------------->| /
| |Mcst Group Join Rsp |grp X={FE1} | | grp with grpDes
| |<======================| | / X created
| <-- Join OK | | |
| | | | | | | |
| | |tmlWrite(grp X)| \ | | | | \
| | |<--------------| | Write to | | |tmlJoin(McId) | | TML updates multicast
| | | | > Multicast Grp. | | |<--------------| | group membership. PL is
~ ~ ~ ~ | Msg sent to FE1 | | McId = {FE1_ChDes} | > only aware of PL layer
~ ~ ~ ~ / only | | | | | multicast group Id, that is,
| | | status --> | | McId]
| | | | /
Multicast Scenario with FE2: Figure 7: Multicast Support: FE1 Joins Group
FE2 PL FE2 TML CE TML CE PL
| | | | Multicast Scenario with FE1 leaving group: Group membership updated
| |STEADY STATE OPERATION | | to exclude FE1
|<--------------|-----------------------|-------------->|
| | | | FE1 PL FE1 TML CE TML CE PL
| | | |
~ ~ ~ ~
~ ~ ~ ~
|tmlMcstGrpJoin | | | \
|-------------->| | | | FE2 joins
| |Mcst Group Join Req | | > Multicast
| |======================>| | | Group. Grp
| | |tmlJoinUpcall | | already exists.
| | |--.--.--.--.-->| | Group members
| |Mcst Group Join Rsp |grp X={FE1,FE2}| | updated.
| |<======================| | /
| <-- Join OK | | |
| | | |
| | |tmlWrite(grp X)| \
| | |<--------------| | Write to
| | | | > Multicast Grp.
| | | | | Msg sent to FE1
~ ~ ~ ~ / and FE2.
~ ~ ~ ~
| | | | | | | |
|tmlMcstGrpLeave| | | \ | | | | \
|-------------->| | | | FE2 leaves | MC Grp Leave Req (McId, FE1) | |
| |Mcst Group Leave Req | | > Multicast |<--------------|-------------------|---------------| | CE:PL Level multicast group
| |======================>| | | Group. Grp [TML | tmlLeave(McId)| | | | leave request sent to FE1:PL
| | |tmlLeaveUpcall | | membership removes |-------------->| | | | that needs to be removed
| | |--.--.--.--.-->| | updated. MC grp | McId = {} | | > from multicast group, McId,
| |Mcst Group Leave Rsp |grp X={FE1} | | info] | | | | | where McId specifies a
| |<======================| | / | <-- status | | | | multicast group Id at the
| <-- Leave OK | | | | | | | | PL layer.
~ ~ ~ ~ | MC Grp Leave Rsp (status) | |
~ ~ ~ ~ |---------------|-------------------|-------------->| /
| | | | | | | |
| | |tmlWrite(grp X)| \ | | | | \
| | |<--------------| | Write to | | |tmlLeave(McId) | | TML removes FE1 from
| | | | > Multicast Grp. | | |<--------------| | multicast group McId.
~ ~ ~ ~ | Msg sent to FE1 | | McId = {FE2_ChDes} | > That leaves only FE2
~ ~ ~ ~ / only | | | | | in the group.
| | | status --> | |
| | | | /
Legend: Figure 8: Multicast Support: FE1 Leaves Group
PL --------> PL : Protocol layer messaging
PL --------> TML: TML API
TML ========> TML: Messaging between TML Layers
TML --.--.--> PL : Events/Notifications/Upcalls
TML ~~~~~~~~> TML: Internal protocol communication
Figure 6: Support for Multicast 6.4.Broadcast Model
The TML layer provides support for broadcast. In the ForCES model,
support is required to broadcast to the FEs from a CE. The
broadcast model is just a special case of multicast, where all FEs
are included. TBD: Is there anything else to be added/discussed
here. Join/Leave messaging also used for broadcast? ForCES draft
also talks of CE broadcast and NE broadcast.
7. Security Considerations 7. Security Considerations
If the CE or FE are in a single box and network operator is running If the CE or FE are in a single box and network operator is running
under a secured environment then it is up to the network under a secured environment then it is up to the network
administrator to turn off all the security functions. This is administrator to turn off all the security functions. This is
configured during the pre-association phase of the protocol. configured during the pre-association phase of the protocol.
When the CEs, FEs are running over IP networks or in an insecure When the CEs, FEs are running over IP networks or in an insecure
environment, this TML uses TLS [8] to provide security. The security environment, this TML uses TLS [8] to provide security. The security
association between the CEs and FEs MUST be established before any association between the CEs and FEs MUST be established before any
ForCES protocol messages are exchanged between the CEs and FEs. ForCES protocol messages are exchanged between the CEs and FEs.
7.1.TLS Usage for this TML 7.1.TLS Usage for this TML
[TBD: Update based on inclusion of IPSec for security.]
This section is applicable for CE or FE endpoints that use the TML This section is applicable for CE or FE endpoints that use the TML
with TLS [8] to secure communication. with TLS [8] to secure communication.
Since CE is master and FEs are slaves, the FEs are TLS clients and Since CE is master and FEs are slaves, the FEs are TLS clients and
CEs are TLS server. The endpoints that implement TLS MUST perform CEs are TLS server. The endpoints that implement TLS MUST perform
mutual authentication during TLS session establishment process. CE mutual authentication during TLS session establishment process. CE
must request certificate from FE and FE needs to pass the requested must request certificate from FE and FE needs to pass the requested
information. information.
skipping to change at page 23, line 9 skipping to change at page 23, line 34
This TML uses TLS to provide security when the NE is in an insecure This TML uses TLS to provide security when the NE is in an insecure
environment. This is because IPsec provides less flexibility when environment. This is because IPsec provides less flexibility when
configuring trust anchors since it is transparent to the application configuring trust anchors since it is transparent to the application
and use of Port identifiers is prohibited within IKE Phase 1. This and use of Port identifiers is prohibited within IKE Phase 1. This
provides restriction for IPsec to configure trust anchors for each provides restriction for IPsec to configure trust anchors for each
application separately and policy configuration is common for all application separately and policy configuration is common for all
applications. applications.
8. IANA Considerations 8. IANA Considerations
The TCP/IP TML needs to have a two well-defined TCP port numbers, The TCP/IP TML needs to have a one well-defined TCP port number,
which needs to be assigned by IANA. The control port is referred to which needs to be assigned by IANA. The control port is referred to
as the TCP_TML_CONTROL_PORT. The data port is referred to as the as the TCP_TML_CONTROL_PORT. [TBD: Add information for data channel
TCP TML DATA PORT. port if required based on the protocol for the data channel.]
9. References 9. Manageability
9.1.Normative References
TBD
10. References
10.1.Normative References
1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026,
October 1996. October 1996.
2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
Levels", RFC2119 (BCP), IETF, March 1997. Levels", RFC2119 (BCP), IETF, March 1997.
3. Khosravi, et al., ÷Requirements for Separation of IP Control and 3. Khosravi, et al., ÷Requirements for Separation of IP Control and
Forwarding÷, RFC 3654, November 2003. Forwarding÷, RFC 3654, November 2003.
skipping to change at page 23, line 38 skipping to change at page 24, line 23
5. L. Yang, et al., ÷ ForCES Forwarding Element Functional Model÷, 5. L. Yang, et al., ÷ ForCES Forwarding Element Functional Model÷,
work in progress÷, July 2004,<draft-ietf-forces-model-03.txt> work in progress÷, July 2004,<draft-ietf-forces-model-03.txt>
6. A. Audu, et al., ˘ Forwarding and Control Element protocol (FACT)" 6. A. Audu, et al., ˘ Forwarding and Control Element protocol (FACT)"
draft-gopal-forces-fact-06.txt, February 2004. draft-gopal-forces-fact-06.txt, February 2004.
7. A. Doria, et al., ÷ForCES protocol specification÷, draft-ietf- 7. A. Doria, et al., ÷ForCES protocol specification÷, draft-ietf-
forces-protocol-00.txt, September 2004. forces-protocol-00.txt, September 2004.
9.2.Informative References 10.2.Informative References
8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. 8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P.
Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
9. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer 9. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
10. R. Stewart, et al., ˘Stream Control Transmission Protocol 10. R. Stewart, et al., ˘Stream Control Transmission Protocol
(SCTP)÷, RFC 2960, October 2000. (SCTP)÷, RFC 2960, October 2000.
skipping to change at page 24, line 28 skipping to change at page 25, line 12
14. H. Balakrishnan, et al. ˘The Congestion Manager÷, RFC 3124, 14. H. Balakrishnan, et al. ˘The Congestion Manager÷, RFC 3124,
June 2001. June 2001.
15. H. Khosravi, S. Lakkavali, ˘Analysis of protocol design issues 15. H. Khosravi, S. Lakkavali, ˘Analysis of protocol design issues
for open standards based programmable routers and switches÷ for open standards based programmable routers and switches÷
[SoftCOM 2004] [SoftCOM 2004]
16. S. Lakkavali, H. Khosravi, ˘ForCES protocol design analysis for 16. S. Lakkavali, H. Khosravi, ˘ForCES protocol design analysis for
protection against DoS attacks÷ [ICCCN 2004] protection against DoS attacks÷ [ICCCN 2004]
10. Acknowledgments 11. Acknowledgments
11. Authors' Addresses 12. Authors' Addresses
Hormuzd Khosravi Hormuzd Khosravi
Intel Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
Phone: 1-503-264-0334 Phone: 1-503-264-0334
Email: hormuzd.m.khosravi@intel.com Email: hormuzd.m.khosravi@intel.com
Furquan Ansari Furquan Ansari
101 Crawfords Corner Road 101 Crawfords Corner Road
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/