[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
                                                       Hormuzd Khosravi
   Internet Draft                                         Shuchi Chawla
   Document: draft-khosravi-forces-tcptml-01.txt            Intel Corp.
   Expires: August 2005                                  Furquan Ansari
   Working Group: ForCES                                   Lucent Tech.
                                                              Jon Maloy
                                                               Ericsson


                                                         February 2005


        TCP/IP based TML (Transport Mapping Layer) for ForCES protocol


  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.


  Conventions used in this document

   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 [2].

   Abstract

   This document defines the TCP/IP based TML (Transport Mapping Layer)
   for the ForCES protocol. It explains the rationale for choosing the
   transport protocols and also describes how this TML addresses all



Khosravi, et al          Expires August 2005                 [Page 1]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   the requirements described in the Forces [3] requirements and ForCES
   protocol [7] document.


                             Table of Contents

   1. Definitions.....................................................3
   2. Introduction....................................................3
   3. Protocol Framework Overview.....................................4
   3.1.1. The PL layer................................................5
   3.1.2. The TML layer...............................................5
   4. TCP/IP TML Overview.............................................5
   4.1. Rationale for using TCP/IP....................................6
   4.2. Separate Control and Data channels............................6
   4.3. Reliability...................................................7
   4.4. Congestion Control............................................8
   4.5. Security......................................................8
   4.6. Addressing....................................................8
   4.7. Prioritization................................................8
   4.8. HA Decisions..................................................8
   4.9. Encapsulations Used...........................................8
   5. TML Messaging...................................................8
   5.1. TML Message Header............................................9
   5.1.1. Version (version)...........................................9
   5.1.2. Upper Layer Protocol Flag (f)...............................9
   5.1.3. Message Type (msgType)......................................9
   5.1.4. TML Message Length (tmlMsgLength)...........................9
   5.1.5. TML Message Body...........................................10
   5.2. TML Messages.................................................10
   5.2.1. Channel Close..............................................10
   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.2. Protocol Initialization and Shutdown Model...................17
   6.2.1. Protocol Initialization....................................17
   6.2.2. Protocol Shutdown..........................................18
   6.3. Multicast Model..............................................20




Khosravi, et al          Expires August 2005                 [Page 2]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   7. Security Considerations........................................22
   7.1. TLS Usage for this TML.......................................22
   8. IANA Considerations............................................23
   9. References.....................................................23
   9.1. Normative References.........................................23
   9.2. Informative References.......................................23
   10. Acknowledgments...............................................24
   11. Authors' Addresses............................................24


1. Definitions

   The following definitions are taken from [3], [5]

   ForCES Protocol - While there may be multiple protocols used within
   the overall ForCES architecture, the term "ForCES protocol" refers
   only to the protocol used at the Fp reference point in the ForCES
   Framework in RFC3746 [RFC3746].  This protocol does not apply to
   CE-to-CE communication, FE-to-FE communication, or to communication
   between FE and CE managers.  Basically, the ForCES protocol works in
   a master-slave mode in which FEs are slaves and CEs are masters.


   ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
   architecture that defines the ForCES protocol messages, the protocol
   state transfer scheme, as well as the ForCES protocol architecture
   itself (including requirements of ForCES TML (see below)).
   Specifications of ForCES PL are defined by this document.

   ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
   ForCES protocol architecture that specifically addresses the
   protocol message transportation issues, such as how the protocol
   messages are mapped to different transport media (like TCP, IP, ATM,
   Ethernet, etc), and how to achieve and implement reliability,
   multicast, ordering, etc.  This document defines a TCP/IP based
   ForCES TML.


2. Introduction

   The ForCES (Forwarding and Control Element Separation) working group
   in the IETF is defining the architecture and protocol for separation
   of control and forwarding elements in network elements such as
   routers.  [3],  [4]  define  both  architectural  and  protocol
   requirements for the communication between CE and FE. The ForCES
   protocol layer [7] describes the protocol specification. It is
   envisioned that the ForCES protocol would be independent of the
   interconnect technology between the CE and FE and can run over



Khosravi, et al          Expires August 2005                 [Page 3]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   multiple  transport  technologies  and  protocol.  Thus  a  Transport
   Mapping Layer (TML) has been defined in the protocol framework that
   will  take  care  of  mapping  the  protocol  messages  to  specific
   transports. This document defines the TCP/IP based TML for the
   ForCES protocol layer. It also addresses all the requirements for
   the TML including security, reliability, etc.


3. Protocol Framework Overview

   The reader is referred to the Framework document [4], and in
   particular sections 3 and 4, for architectural overview and where
   and how the ForCES protocol fits in.  There may be some content
   overlap between the ForCES protocol draft [7] and this section in
   order to provide clarity.

   The ForCES protocol constitutes two pieces: the PL and TML layer.
   This is depicted in Figure 1 below.

            +------------------------------------------------
            |               CE PL layer                     |
            +------------------------------------------------
            |              CE TML layer                     |
            +------------------------------------------------
                                      ^
                                      |
                         ForCES       |   (i.e. Forces data + control
                         PL           |    packets )
                         messages     |
                         over         |
                         specific     |
                         TML          |
                         encaps       |
                         and          |
                         transport    |
                                      |
                                      v
            +------------------------------------------------
            |              FE TML layer                     |
            +------------------------------------------------
            |               FE PL layer                     |
            +------------------------------------------------

                          Figure 1: ForCES Interface

   The PL layer is in fact the ForCES protocol.  Its semantics and
   message layout are defined in [7].  The TML Layer is necessary to
   connect two ForCES PL layers as shown in Figure 1 above.




Khosravi, et al          Expires August 2005                 [Page 4]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005


   Both the PL and TML layers are standardized by the IETF.  While only
   one PL layer is defined, different TMLs are expected to be
   standardized.  To interoperate the TML layer at the CE and FE are
   expected to be of the same definition.

   On transmit, the PL layer delivers its messages to the TML layer.
   The TML layer delivers the message to the destination TML layer(s).
   On reception, the TML delivers the message to its destination PL
   layer(s).

3.1.1.The PL layer

   The PL is common to all implementations of ForCES and is
   standardized by the IETF [7].  The PL layer is responsible for
   associating an FE or CE to an NE.  It is also responsible for
   tearing down such associations.  An FE uses the PL layer to throw
   various subscribed-to events to the CE PL layer as well as respond
   to various status requests issued from the CE PL.  The CE configures
   both the FE and associated LFBs attributes using the PL layer.  In
   addition the CE may send various requests to the FE to activate or
   deactivate it, reconfigure itÆs HA parameterization, subscribe to
   specific events etc.

3.1.2.The TML layer

   The TML layer is essentially responsible for transport of the PL
   layer messages.  The TML is where the issues of how to achieve
   transport level reliability, congestion control, multicast,
   ordering, etc. are handled.  It is expected more than one TML will
   be standardized.  The different TMLs each could implement things
   differently based on capabilities of underlying media and transport.
   However, since each TML is standardized, interoperability is
   guaranteed as long as both endpoints support the same TML.  All
   ForCES Protocol Layer implementations should be portable across all
   TMLs, because all TMLs have the same top edge semantics.


4. TCP/IP TML Overview

   The TCP/IP TML consists of two TCP connections between the CE and FE
   over which the protocol messages are exchanged. One of the
   connections is called the control channel, over which control
   messages are exchanged, the other is called data channel over which
   external protocol packets, such as routing packets will be
   exchanged. The TCP connections will use unique server port numbers
   for each of the channels. In addition to this, this TML will provide
   mechanisms to prioritize the messages over the different channels.




Khosravi, et al          Expires August 2005                 [Page 5]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005


   Some of the rationale for choosing this transport mechanism as well
   as explanation of how it meets the TML requirements is explained
   below.

4.1.Rationale for using TCP/IP

   TCP meets all the reliability requirements (no losses, no data
   corruption, no re-ordering of data) for the ForCES protocol/TML and
   also provides congestion control mechanism, which is important to
   meet the scalability requirement. In addition, it helps with
   interoperability since TCP is a well-understood, widely deployed
   transport protocol. Using TCP also enables this TML and the protocol
   to work seamlessly in single hop and multihop scenarios.

4.2.Separate Control and Data channels

   The ForCES NEs are subject to Denial of Service (DoS) attacks
   [Requirements 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
   communication between the CEs and FEs. In order to protect against
   this situation, the TML uses separate control and data channels for
   communication between the CEs and FEs. Figure 2 below illustrates
   the different communication channels between the CEs and the FEs;
   the communication channels for support of High Availability with
   redundant CEs are also included.

                           ACTIVE CE              STANDBY CE
                    +-------------------+  +-------------------+
                    | CE: PL            |  | CE: PL            |
                    +-------------------+  +-------------------+
                    | CE: TML           |  | CE: TML           |
                    +-------------------+  +-------------------+
                    | CE: TCP           |  | CE: TCP           |
                    +-------------------+  +-------------------+
                      | |   | |    | |       |  |     |  |
                      | .   | .    | .       |  .     |  .
                      | |   | |    | |       |  |     |  |
                      | .   | .    | .       |  .     |  .
                      | |   | |    | |    Cc1Æ Cd1Æ Cc2Æ Cd2àCcnÆ CdnÆ
                      | .   | .    | .
            +-Cc1-----+ |   | |    | +-.-.-.-.-.Cdn.-+
            |  +-Cd1-.-.+   | .    +--------Ccn---+  |
            |  |            | |                   |  .
            |  .        +Cc2+ .                   |  |
            |  |        | +Cd2+                   |  .
            |  .        | |                       |  |



Khosravi, et al          Expires August 2005                 [Page 6]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

         +-----------+ +-----------+          +-----------+
         | FE: TCP   | | FE: TCP   |   . . .  | FE: TCP   |
         +-----------+ +-----------+          +-----------+
         | FE: TML   | | FE: TML   |          | FE: TML   |
         +-----------+ +-----------+          +-----------+
         | FE: PL    | | FE: PL    |          | FE: PL    |
         +-----------+ +-----------+          +-----------+
           FE1            FE2                    FEn
        \-------------V------------/
                 FE 1+1 Redundancy

   Legend:
       ---- Cc# : Unicast Control Channel between Active CE and FE#
       -.-. Cd# : Unicast Data Channel between Active CE and FE#

       ---- Cc#Æ: Unicast Control Channel between Standby CE and FE#
       -.-. Cd#Æ: Unicast Data Channel between Standby CE and FE#

                          Figure 2: CE-FE Communication Channels


   The data channel carries the control protocol packets such as RIP,
   OSPF messages as outlined in Requirements [3] Section 7 #10, which
   are carried in ForCES Packet Redirect messages [7], between the CEs
   and FEs. All the other ForCES messages, which are used for
   configuration/capability exchanges, event notification, etc, are
   carried over the control channel. The data channel is set up only
   after the control channel is set up. By default, the data channel is
   established on the CE control channel port number +1.

   The reliability requirements for the data channel messages are
   different from that of the control messages [Reqs] i.e. they donÆt
   require strict reliability in terms of retransmission, etc. However
   congestion control is important for the data channel because in case
   of DoS attacks, if an unreliable transport such as UDP is used for
   the data traffic, it can more easily overflow the physical
   connection, overwhelming the control traffic with congestion. Thus
   we need a transport protocol that provides congestion control but
   does not necessarily provide full reliability. Datagram Congestion
   Control Protocol (DCCP) [11], which is currently being defined, is a
   transport protocol that exactly meets this requirement. However
   since it is currently not an IETF standard RFC, and the authors are
   unaware of any existing implementations, this TML uses TCP as
   transport protocol for the data channel (for IP interconnect). TCP
   provides the congestion control mechanism required for the data
   channel and its wide deployment eases interoperability.

4.3.Reliability




Khosravi, et al          Expires August 2005                 [Page 7]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005


   TCP provides the reliability (no losses, no data corruption, no re-
   ordering of data) required for ForCES protocol control messages.

4.4.Congestion Control

   TCP provides congestion control needed to satisfy this requirement.

4.5.Security

   This TML uses TLS [8] to provide security in insecure environments.
   Please see section 7 on security considerations for more details.

4.6.Addressing

   This TML uses addressing provided by IP layer. For unicast
   addressing/delivery, it uses the TCP connection between the CE and
   FE. For multicast/broadcast addressing/delivery, this TML uses
   multiple TCP connections between the CE and FEs.

4.7.Prioritization

   This TML provides prioritization of messages sent over control
   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
   this are TBD.

4.8.HA Decisions

   The TML layer supports heartbeat messages between peer TML layers to
   indicate liveness of the entity generating it.  The frequency of the
   heartbeat message may be specified at protocol initialization time.

4.9.Encapsulations Used

   TML adds its own header on all ForCES protocol messages that it
   receives, and additionally on messages it generates. The ForCES
   protocol and TML messages are further encapsulated with a TCP/IP
   header.  The format of the TML header is specified in Section 5.

5. TML Messaging

   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




Khosravi, et al          Expires August 2005                 [Page 8]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   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.





Khosravi, et al          Expires August 2005                 [Page 9]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

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
   Layer in response to a join request message.

   ForCES protocol usage: If only FEs may be the leaves in a multicast
   group, this message is generated by the CE TML and sent to the FE
   TML, in response to the join request message received from the FE
   TML.





Khosravi, et al          Expires August 2005                [Page 10]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

5.2.5.Multicast Group Leave Request

   The multicast group leave request message is triggered by a request
   from the PL layer to leave a specific multicast group. The peer TML
   layer on receiving this request removes the specified multicast
   group if the entity requesting to leave is the only member of the
   group.  Else, it updates the membership of the group to exclude the
   entity requesting the leave.

   ForCES protocol usage: If 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
   leave request from the FE PL.

5.2.6.Multicast Group Leave Response

   The multicast group leave response message is generated by the TML
   Layer in response to a leave request message.

   ForCES protocol usage: If only FEs may be the leaves in a multicast
   group, this message is generated by the CE TML and sent to the FE
   TML, in response to the leave request message received from the FE
   TML.


6. TML Interface to Upper layer Protocol

   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
   defines the interface to the upper layer protocol.  This interface
   should be used only as a guideline in implementing the API.
   Additionally, although the current interface is defined mainly as a
   synchronous interface, the interface may be implemented to be
   asynchronous if desired.

6.1.TML API

6.1.1.TML Initialize

   status tmlInit(
     in  channelType,
     in  initAttributes)

   Input Parameters:
     channelType: control versus data channel
     initAttributes: initialization parameters

   Output Parameters:
     none




Khosravi, et al          Expires August 2005                [Page 11]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005


   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   tmlInit() enables establishment of communication channels on the
   entity that this API is invoked.  Optionally specifies attributes if
   any, for initialization. This call does not however result in the
   setup of any channels.

   ForCES Usage Model:
   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
   invoked once for every class of TML channels on a per channel type
   basis (control channel versus data channel).  For example, say for
   control messaging, the CE communicates with five FEs using TCP TML
   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
   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.


6.1.2.TML Channel Open

   status tmlOpen(
     in  channelType,
     in  elementId,
     in  channelMode,
     in  channelAttributes,
     in  eventHandlerCallBack,
     out channelDescriptor)

   Input Parameters:
     channelType: control channel or data channel
     elementId: Specific CE for which channel needs to be setup
     channelMode: unicast versus multicast
     channelAttributes: channel establishment parameters
     eventHandlerCallback: Callback function to be invoked on event
   generation

   Output Parameters:
     channelDescriptor: handle to communication channel

   Returns:
     status: SUCCESS
             Errors TBD





Khosravi, et al          Expires August 2005                [Page 12]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   Synopsis:
   tmlOpen() results in a communication channel of type channelType
   (control versus data), being established with the specified
   elementId.  The channel may be specified as unicast or multicast via
   channelMode.  This call may either trigger the establishment of the
   channel, or if the channel is already established, it only results
   in a registration for that channel.  In either case, if successful,
   a handle to the open channel is returned via a channelDescriptor.
   If this call triggers the establishment of the channel, the channel
   is established using the channelAttributes parameter specified to
   the call.  Once the channel is setup (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:
   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.
   On each FE, it is invoked once per channel that the FE wishes to
   setup with the CE.

   Notes:
   In the case of TCP TML, since there is no inherent support for
   multicast, regardless of the channelMode specified, the specified
   channel would be setup as a unicast channel; however, the unicast
   channel would be able to support pseudo multicast.  Hence, there is
   no need to set up a distinct channel for unicast and a distinct
   channel for multicast in the case of TCP TML (as may be the case for
   UDP TML).



6.1.3. TML Channel Close

   status tmlClose(
     in  channelDescriptor
     in  mode)

   Input Parameters:
     channelDescriptor: handle to communication channel to be
   terminated
     mode: mode of operation for the close û forced versus controlled

   Output Parameters:
     none





Khosravi, et al          Expires August 2005                [Page 13]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   Tears down/terminates specified communication channel.  No further
   CE PL û FE PL messaging is possible after this.  If the mode is
   specified as controlled, current messages that are pending in the
   TML layer shall be sent, but no new messages shall be accepted by
   the TML layer on this channel.  In the forced model, 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:
   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
   that the channel has been shutdown, which results in an upcall to
   the CE PL.  This will result in the CE PL also shutting down its end
   of the channel.

6.1.4.TML Channel Write

   status tmlWrite(
     in  channelDescriptor,
     in  msg,
     in  msgSize,
     in  timeout,
     out bytesWritten)

   Input Parameters:
     channelDescriptor: handle to communication channel to be written
   to
     msg: message to be sent
     msgSize: size of message to be sent
     timeout: specifies blocking or non-blocking write.  Value of -1
   implies blocking write (wait forever), value of 0 implies non-
   blocking write

   Output Parameters:
     bytesWritten: number of bytes actually transmitted

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:





Khosravi, et al          Expires August 2005                [Page 14]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   Sends message over the specified channel.  If the specified
   channelDescriptor is associated with a multicast group, the message
   will be sent to all members of the group.  This does not imply that
   the message has actually been transmitted.  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:
   This API may be invoked by either the FE PL or the CE PL.


6.1.5.TML Channel Read

   status tmlRead(
     in  channelDescriptor,
     in  msgBuf,
     in  timeout,
     out bytesRead)

   Input Parameters:
     channelDescriptor: handle to communication channel to be read from
     msgBuf: buffer into which message is to be read
     timeout: specifies blocking or non-blocking read.  Value of -1
   implies blocking read (wait forever), value of 0 implies non-
   blocking read

   Output Parameters:
     bytesRead: number of bytes actually read

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   Reads message on the specified channel. 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
   available, the API returns with an error.
   If a non-blocking read is executed, the caller of the API is
   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





Khosravi, et al          Expires August 2005                [Page 15]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   only supported on a write; a read is always associated with reading
   from a single channel.

6.1.6.TML Multicast Group Join

   status tmlMulticastGroupJoin(
     in  groupAttributes)

   Input Parameters:
     groupAttributes: Attributes associated with the multicast group to
   be joined

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   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
   results in the creation of the group and the allocation of a
   groupDescriptor (which is equivalent to a channelDescriptor). Once a
   member of this group, the entity calling this API will be capable of
   receiving messages addressed to this multicast group.

   ForCES Usage Model:
   If the intent is that only FEs can be members of a multicast group
   and only a CE can be the source of a multicast, this API would be
   invoked on the FE that wishes to join a multicast group.

6.1.7.TML Multicast Group Leave

   status tmlMulticastGroupLeave(
     in  groupAttributes)

   Input Parameters:
     groupAttributes: Attributes associated with the multicast group to
   leave

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD





Khosravi, et al          Expires August 2005                [Page 16]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   Synopsis:
   Leaves the specified multicast group it had previously joined. Once
   an entity is not a member of the multicast group, it is no longer
   capable of receiving messages addressed to group.  If this leave
   request is associated with the only member of the group, the
   multicast group is removed, and its associated groupDescriptor
   invalidated.

   ForCES Usage Model:
   If the intention is that only FEs can be members of a multicast
   group and only a CE can be the source of a multicast, this API would
   be invoked on the FE that wishes to leave a group it had previously
   joined.

6.2.Protocol Initialization and Shutdown Model

   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
   of the channels, using the TML interface defined above. In this
   model, the peer TML Layers may establish the control and data
   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
   channels; this is left as an implementation decision.  Both modes
   may also be supported within an implementation.

6.2.1.Protocol Initialization

   The control channel must be established between the FE TML and the
   CE TML for establishment of association to proceed.  This channel
   will be used for messages related to the association setup and
   capability query.  The data channel must be established no later
   than the response from the FE to the CE Topology query message.

   Figure 4 illustrates the initialization model where the PL layer via
   an interface provided by the TML Layer, triggers the setup of the
   control and data channels.


        FE PL           FE TML                  CE TML          CE PL
           |               |                       |               | \
        /  |               |                       | tmlInit(Cc)   | |
   FE   |  |               |                       |<--------------| > CE Init/
 Init/  <  |               |                       | tmlInit(Cd)   | | Bootup
 Bootup |  |               |                       |<--------------| /
        \  |               |                       |               |
           | tmlOpen(Cc)   |                       |               |
           |-------------->|                       |               | \
           |               |TCP CtrlChan(Cc) Setup |               | |
           |               |~~~~~~~~~~~~~~~~~~~~~~>|               | | Setup control



Khosravi, et al          Expires August 2005                [Page 17]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

           |               |CtrlChann(Cc) Setup Rsp|               | > channel if not
           |               |<~~~~~~~~~~~~~~~~~~~~~~|               | | already
           |  <-- CcDes    |                       |               | | setup
           |tmlEvent(CcUp) |                       |tmlEvent(CcUp) | /
           |<--.--.--.--.--|                       |--.--.--.--.-->|
           |               |                       |     CcDes     |
           | tmlOpen(Cd)   |                       |               |
           |-------------->|                       |               | \
           |               |TCP DataChann(Cd) Setup|               | | Setup data
           |               |~~~~~~~~~~~~~~~~~~~~~~>|               | | channel if not
           |               |DataChann(Cd) Setup Rsp|               | > channel if not
           |               |<~~~~~~~~~~~~~~~~~~~~~~|               | | already
           |  <-- CdDes    |                       |               | | setup
           |tmlEvent(CdUp) |                       |tmlEvent(CdUp) | /
           |<--.--.--.--.--|                       |--.--.--.--.-->|
           |               |                       |     CdDes     |
           |               |   Asso Setup Req      |               |
           |---------------|-----------------------|-------------->|
           |               |   Asso Setup Rsp      |               |
           |<--------------|-----------------------|---------------|
           |               |                       |               |
           |               |    Capability Query   |               |
           |<--------------|-----------------------|---------------|
           |               | Capability Query Rsp  |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               |   Topology Query      |               |
           |<--------------|-----------------------|---------------|
           |               | Topology Query Rsp    |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               |                       |               |


Legend:
 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 4: Protocol Initialization (Channel Setup)

6.2.2.Protocol Shutdown

The control channel teardown must occur only after the association
teardown has occurred.  The data channel teardown may occur no earlier
than the association teardown.




Khosravi, et al          Expires August 2005                [Page 18]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

The PL Layer may completely shutdown a channel via invocation of the
tmlClose() API.  When the PL layer shuts down a channel, the channel is
torn down; hence ForCES messaging between the CE and FE is no longer
possible over that channel.  A subsequent tmlOpen() triggers
establishment of the channel.  This scenario is illustrated in Figure
5.

        FE PL           FE TML                  CE TML          CE PL
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               | Config Request        |               |
           |<--------------|-----------------------|---------------|
           |               | Config Response       |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               | Association Teardown  |               |
           |<--------------|-----------------------|---------------|
           |               |                       |               |
           |               |                       |               |
           |tmlClose(CdDes)|                       |               | \
           |-------------->|                       |               | | Data Channel
           |               |DataChan(Cd) Close     |               | | teardown; it no
           |               |======================>|               | > longer exists.
           |<-- Cd Close OK|                       |tmlCloseUpcall | | PL Layer can no
           |               |                       |--.--.--.--.-->| | longer use Cd;
           |               |                       |               | | TML msging also
           |               |                       |               | / not possible.
           |               |                       |               |
           |tmlClose(CcDes)|                       |               | \
           |-------------->|                       |               | | 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
           |               |TCP CtrlChan(Cc) Setup |               | | needs to launch
           |               |~~~~~~~~~~~~~~~~~~~~~~>|               | > setup of the
           |               |CtrlChann(Cc) Setup Rsp|               | | channel since
           |               |<~~~~~~~~~~~~~~~~~~~~~~|               | | shutdown had
           |   <-- CcDes   |                       |               | | torn the
           |tmlEvent(CcUp) |                       |tmlEvent(CcUp) | | channel down
           |<--.--.--.--.--|                       |--.--.--.--.-->| /
           |               |                       |     CcDes     |




Khosravi, et al          Expires August 2005                [Page 19]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

Legend:
 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 5: Protocol Shutdown

6.3.Multicast 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,
   the CE is the source or root of the multicast and the FEs are the
   leaves.

   Support for multicast requires that a channel for supporting
   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
   messaging since multicast mode is simulated using unicast channels
   in this case. Once the channel is open, FEs may join and leave
   specified multicast groups.  The first ômulticast group joinö
   request from an FE to a CE for a specific multicast group results in
   the creation of the group and an allocation of a group descriptor
   (which is similar to a channel descriptor) for the group.  The
   ômulticast group leaveö request from an FE to the CE on a multicast
   group with just that one member results in the group being removed
   and the descriptor deallocated. A tmlWrite() on a unicast channel
   descriptor results in a unicast message being sent to the FE
   associated with the channel.  A tmlWrite() on a group descriptor
   results in multicast messaging. Figure 6 illustrates a multicast
   scenario with 2 FEs, FE1 and FE2.  In the first case, FE1 joins a
   multicast group.  In the second case, FE2 joins the same multicast
   group, and leaves the group some time later.

   Multicast Scenario with FE1:
        FE1 PL          FE1 TML                  CE TML          CE PL
           |               |                       |               |
           |               |STEADY STATE OPERATION |               | \ Channel for
           |<--------------|-----------------------|-------------->| > multicast msgs
           |               |                       |               | | already exists
           |               |                       |               | /  via tmlOpen()
           ~               ~                       ~               ~
           ~               ~                       ~               ~
           |tmlMcstGrpJoin |                       |               | \
           |-------------->|                       |               | | FE1 joins
           |               |Mcst Group Join Req    |               | | Multicast                                                                  st           |               |======================>|               | > Group. 1 join
           |               |                       |tmlJoinUpcall  | | request for




Khosravi, et al          Expires August 2005                [Page 20]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

           |               |                       |--.--.--.--.-->| | group, hence
           |               |Mcst Group Join Rsp    |grp X={FE1}    | | grp with grpDes
           |               |<======================|               | / X created
           |  <-- Join OK  |                       |               |
           |               |                       |               |
           |               |                       |tmlWrite(grp X)| \
           |               |                       |<--------------| | Write to
           |               |                       |               | > Multicast Grp.
           ~               ~                       ~               ~ | Msg sent to FE1
           ~               ~                       ~               ~ / only

   Multicast Scenario with FE2:
        FE2 PL          FE2 TML                  CE TML          CE PL
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               |                       |               |
           |               |                       |               |
           ~               ~                       ~               ~
           ~               ~                       ~               ~
           |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
           |               |Mcst Group Leave Req   |               | > Multicast
           |               |======================>|               | | Group. Grp
           |               |                       |tmlLeaveUpcall | | membership
           |               |                       |--.--.--.--.-->| | updated.
           |               |Mcst Group Leave Rsp   |grp X={FE1}    | |
           |               |<======================|               | /
           | <-- Leave OK  |                       |               |
           ~               ~                       ~               ~
           ~               ~                       ~               ~
           |               |                       |               |
           |               |                       |tmlWrite(grp X)| \
           |               |                       |<--------------| | Write to




Khosravi, et al          Expires August 2005                [Page 21]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

           |               |                       |               | > Multicast Grp.
           ~               ~                       ~               ~ | Msg sent to FE1
           ~               ~                       ~               ~ /  only

Legend:
 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


7. Security Considerations

   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
   administrator to turn off all the security functions. This is
   configured during the pre-association phase of the protocol.

   When the CEs, FEs are running over IP networks or in an insecure
   environment, this TML uses TLS [8] to provide security. The security
   association between the CEs and FEs MUST be established before any
   ForCES protocol messages are exchanged between the CEs and FEs.


7.1.TLS Usage for this TML

   This section is applicable for CE or FE endpoints that use the TML
   with TLS [8] to secure communication.

   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
   mutual authentication during TLS session establishment process. CE
   must request certificate from FE and FE needs to pass the requested
   information.

   We recommend ôTLS-RSA-with-AES-128-CBC-SHAö cipher suite, but CE or
   FE may negotiate other TLS cipher suites. TLS must be used for all
   control channel messages. TLS is optional for the data channel since
   data channel packets are not encrypted externally to the NE.

   This TML uses TLS to provide security when the NE is in an insecure
   environment. This is because IPsec provides less flexibility when
   configuring trust anchors since it is transparent to the application
   and use of Port identifiers is prohibited within IKE Phase 1. This
   provides restriction for IPsec to configure trust anchors for each




Khosravi, et al          Expires August 2005                [Page 22]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   application separately and policy configuration is common for all
   applications.


8. IANA Considerations

   The TCP/IP TML needs to have a two well-defined TCP port numbers,
   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
   TCP TML DATA PORT.

9. References
9.1.Normative References

  1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026,
     October 1996.

  2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement
     Levels", RFC2119 (BCP), IETF, March 1997.

  3. Khosravi, et al., öRequirements for Separation of IP Control and
     Forwardingö, RFC 3654, November 2003.

  4. L. Yang, et al., ö ForCES Architectural Frameworkö, RFC 3746,
     April 2004.

  5. L. Yang, et al., ö ForCES Forwarding Element Functional Modelö,
     work in progressö, July 2004,<draft-ietf-forces-model-03.txt>

  6. A. Audu, et al., ô Forwarding and Control Element protocol (FACT)"
     draft-gopal-forces-fact-06.txt, February 2004.

  7. A. Doria, et al., öForCES protocol specificationö, draft-ietf-
     forces-protocol-00.txt, September 2004.


9.2.Informative References


  8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P.
     Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

  9. Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
     Security over Stream Control Transmission Protocol", RFC 3436,
     December 2002.





Khosravi, et al          Expires August 2005                [Page 23]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

  10.  R. Stewart, et al., ôStream Control Transmission Protocol
     (SCTP)ö, RFC 2960, October 2000.

  11.  E. Kohler, M. Handley, S. Floyd, J. Padhye, ôDatagram
     Congestion Control Protocol (DCCP)ö, draft-ietf-dccp-spec-04.txt,
     June 2003.

  12.  Floyd, S., ôCongestion Control Principlesö, RFC 2914, September
     2000.

  13.  A. Doria, F. Hellstrand, K. Sundell, T. Worster, ôGeneral
     Switch Management Protocol (GSMP) V3ö, RFC 3292, June 2002.

  14.  H. Balakrishnan, et al. ôThe Congestion Managerö, RFC 3124,
     June 2001.

  15.  H. Khosravi, S. Lakkavali, ôAnalysis of protocol design issues
     for open standards based programmable routers and switchesö
     [SoftCOM 2004]

  16.  S. Lakkavali, H. Khosravi, ôForCES protocol design analysis for
     protection against DoS attacksö [ICCCN 2004]


10. Acknowledgments


11. Authors' Addresses

   Hormuzd Khosravi
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124
   Phone: 1-503-264-0334
   Email: hormuzd.m.khosravi@intel.com


   Furquan Ansari
   101 Crawfords Corner Road
   Holmdel, NJ 07733
   USA
   Phone: +1 732-949-5249
   Email: furquan@lucent.com

   Jon Maloy
   Ericsson Research Canada
   8400 Boul Decarie
   Ville Mont-Royal, Quebec H4P 2N2



Khosravi, et al          Expires August 2005                [Page 24]


Internet Draft  TCP/IP based TML for ForCES protocol  February 2005

   Canada
   Phone: 1-514-345-7900
   Email: jon.maloy@ericsson.com

   Shuchi Chawla
   Intel
   2111 NE 25th Avenue
   Hillsboro, OR 97124
   Phone: 1-503-712-4539
   Email: shuchi.chawla@intel.com


   Copyright Statement

   Copyright (C) The Internet Society (year).  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.

   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.


























Khosravi, et al          Expires August 2005                [Page 25]