Hormuzd Khosravi
   Internet Draft                                         Shuchi Chawla
   Document: draft-ietf-forces-tcptml-01.txt draft-ietf-forces-tcptml-02.txt                Intel Corp.
   Expires: January September 2006                               Furquan Ansari
   Working Group: ForCES                                   Lucent Tech.
                                                              Jon Maloy
                                                               Ericsson

                                                         July 2005

     March 2006

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

  Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

  Copyright Notice

      Copyright (C) The Internet Society (2005). (2006).

  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 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
   the requirements described in the Forces [3] requirements and ForCES
   protocol [7] [5] document.

                             Table of Contents

   1. Definitions.....................................................2 Definitions.....................................................3
   2. Introduction....................................................3
   3. Protocol Framework Overview.....................................3 Overview.....................................4
   3.1.1. The PL layer................................................5
   3.1.2. The TML layer...............................................5
   4. TCP/IP IP TML Overview.............................................5 Overview.................................................5
   4.1. Rationale for using TCP/IP....................................5 TCP and DCCP..............................6
   4.2. Separate Control and Data channels............................6
   4.3. Reliability...................................................7 Reliability...................................................8
   4.4. Congestion Control............................................8
   4.5. Security......................................................8
   4.6. Addressing....................................................8
   4.7. Prioritization................................................8 Prioritization................................................9
   4.8. HA Decisions..................................................8 Decisions..................................................9
   4.9. Encapsulations Used...........................................9 Used..........................................10
   5. TML Messaging...................................................9 Messaging..................................................10
   6. TML Interface to Upper layer Protocol...........................9 Protocol..........................10
   6.1. TML Service Interface........................................10
   6.1.1. TML Initialize.............................................10
   6.1.2. TML Channel Open...........................................11
   6.1.3. TML Channel Close..........................................12
   6.1.4. TML Channel Write..........................................13
   6.1.5. TML Channel Read...........................................14
   6.1.6. TML Multicast Group Join...................................15
   6.1.7. TML Multicast Group Leave..................................16 Interface Overview...............................10
   6.2. Protocol Initialization and Shutdown Model...................17 Model...................11
   6.2.1. Protocol Initialization....................................17 Initialization....................................11
   6.2.2. Protocol Shutdown..........................................19 Shutdown..........................................13
   6.3. Multicast Model..............................................20 Model..............................................14
   6.4. Broadcast Model..............................................22 Model..............................................17
   7. Security Considerations........................................22 Considerations........................................17
   7.1. TLS Usage for this TML.......................................23 Securing TML...................................17
   7.2. IPSec Usage for securing TML.................................17
   8. IANA Considerations............................................23 Considerations............................................18
   9. Manageability..................................................23 Manageability..................................................18
   10. References....................................................23 References....................................................18
   10.1. Normative References........................................23 References........................................18
   10.2. Informative References......................................24 References......................................18
   11. Acknowledgments...............................................25
   12. Acknowledgments...............................................19
   Appendix A. TML Service Interface................................19
   A.1.  TML Initialize.............................................19
   A.2.  TML Channel Open...........................................20
   A.3.  TML Channel Close..........................................21
   A.4.  TML Channel Write..........................................22
   A.5.  TML Channel Read...........................................23
   A.6.  TML Multicast Group Join...................................24
   A.7.  TML Multicast Group Leave..................................25
   Authors' Addresses............................................25 Addresses................................................26

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]. [4].  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 an 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] [5] 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
   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 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] [5] 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]. [5].  The TML Layer is necessary to
   connect two ForCES PL layers as shown in Figure 1 above.

   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]. [5].  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 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    IP TML Overview

   [TBD: Update this section based on the protocol selected for the
   data channel.]

   The TCP/IP 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
   control channel is a TCP connection; the data channel is a DCCP
   connection.  The TCP and DCCP 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.

   Some of the rationale for choosing this these transport mechanism mechanisms as
   well as explanation of how it meets they meet the TML requirements is
   explained below. The ForCES protocol defines requirements to be met
   by the TML.  However, the requirements in the draft do not always
   differentiate between control versus data messaging.  The assumption
   is that the requirements for messaging over the data channel are a
   subset of those specified for control messaging.  When such an
   assumption is made, it is explicitly specified and the justification
   for the same stated.

4.1.Rationale for using TCP/IP TCP and DCCP

   For control messaging, 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 reliability requirements for the data channel messages are subject to Denial
   different from that 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 messages [3] i.e. they don’t
   require strict reliability in an attempt to disrupt the operation terms of and the
   communication between the CEs and FEs. In order to protect against
   this situation, the TML uses separate retransmission, etc. However
   congestion control and data channels is important for
   communication between the CEs and FEs. Figure 2 below illustrates the different communication channels 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) [9], which is on the RFC track is a
   transport protocol that exactly meets this requirement.

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. As
   an example, the communication channels for support of High
   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
                    +-------------------+  +-------------------+
                    | CE: PL            |  | CE: PL            |
                    +-------------------+  +-------------------+
                    | CE: TML           |  | CE: TML           |
                    +-------------------+  +-------------------+
                    | CE: TCP TCP/DCCP      |  | CE: TCP TCP/DCCP      |
                    +-------------------+  +-------------------+
                      | |    | |    | |       |  |     |  |
                      | .    | .    | .       |  .     |  .
                      | |    | |    | |       |  |     |  |
                      | .    | .    | .       |  .     |  .
                      | |    | |    | |    Cc1Æ Cd1Æ Cc2Æ Cd2àCcnÆ CdnÆ    Cc1’ Cd1’ Cc2’ Cd2…Ccn’ Cdn’
                      | .    | .    | .
            +-Cc1-----+ |    | |    | +-.-.-.-.-.Cdn.-+
            |  +-Cd1-.-.+    | .    +--------Ccn---+  |
            |  |             | |                   |  .
            |  .         +Cc2+ .                   |  |
            |  |         | +Cd2+                   |  .
            |  .         | |                       |  |
         +-----------+ +-----------+          +-----------+
         | FE: TCP   | | FE: TCP   |
         +------------+ +------------+          +------------+
         |FE: TCP/DCCP| |FE: TCP/DCCP|   . . .  | FE: TCP   |
         +-----------+ +-----------+          +-----------+  |FE: TCP/DCCP|
         +------------+ +------------+          +------------+
         | 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#Æ: Cc#’: Unicast Control Channel between Standby CE and FE#
       -.-. Cd#Æ: 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], [5], 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

4.3.Reliability

   TCP provides the CE control channel port number +1.

   The reliability requirements for the (no losses, no data channel messages are
   different from that corruption, no re-
   ordering of the data) required for ForCES protocol control messages [Reqs] i.e. they donÆt
   require messages.

   As mentioned earlier, as per [3], strict reliability in terms of retransmission, etc. However
   congestion control is important not a
   requirement for payload carried over the data channel because in case channel.  Hence, the
   use of DoS attacks, if an unreliable transport such as UDP DCCP is used adequate 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 channel.

4.4.Congestion Control

   TCP 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, needed to satisfy this TML uses TCP as
   transport protocol requirement
   for the data channel (for IP interconnect). TCP control channel.

   DCCP provides the congestion control mechanism required to satisfy this requirement for the
   data
   channel and its wide deployment eases interoperability.

4.3.Reliability

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

4.4.Congestion Control mechanisms – TCP provides
   like congestion control needed specified with a CCID of 2 and TFRC
   congestion control specified with a CCID of 3.  The DCCP channel may
   use either of these mechanisms; the CE and the FE may be configured
   with the mechanism to satisfy this requirement. be used.  The default CCID to be used if none
   is configured is CCID 2 which provides TCP like congestion control.

4.5.Security

   This

   The TML channel can be secured in multiple ways. The default mode is
   to support the “no security”, a mode that is commonly used when it
   is determined that securing the ForCES channel is not needed (e.g.
   closed-box scenario). For scenarios where security is important, the
   TML uses either the TLS [8] [6] or the IPSec [15] mechanisms to provide secure
   the channel(s). The security in insecure environments. mode selection is normally done through
   configuration on either ends. Note that the TML will operate
   correctly only when both the ends are configured with the same
   security mechanism. Please see section 7 on security considerations
   for more details.
   [TBD: Update based on IPSec/TLS decision.]

4.6.Addressing

   This TML uses addressing provided by IP layer.

   For unicast
   addressing/delivery, addressing/delivery of control messages, it uses the TCP
   connection between the CE and
   FE for control messaging. FE. For multicast/broadcast
   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

   For unicast addressing/delivery over the data channel, it uses the
   DCCP connection between the CE and FE.  Multicast/broadcast
   addressing and delivery is not supported over the data channel; data
   messages may only be sent from the CE to the FEs using unicast
   FEIds. If multicast support is required, the higher level protocol
   being carried over the data channel.] channel is responsible for it.

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. Additionally it
   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

   The TML layer supports transports the heartbeat messages between peer TML layers generated at the PL layer
   to
   indicate detect liveness of the entity generating it. CE/FE.  The frequency TML does not generate any
   heartbeat messages of its own.  The PL heartbeat messages are
   carried over the control channel.

   TBD:
   Liveliness detection over the data channel -- options
   1. Carry the same PL heartbeat message may be specified at protocol initialization time.

   [TBD: Remove this? Use liveliness message at TCP layer?  What about
   for over both the control and
      data channel?  What if channels, that is, multicast the protocol doesnÆt support such a
   message?  If a heartbeat message over the 2
      channels.  The heartbeat response is required terminated at the TML layer
      and a single response generated for the PL layer since the PL
      layer is unaware the message was sent over two distinct channels.
   2. Use a TML generated heartbeat message for the data channel, does that imply channel.  Note
      that this introduces TML Layer messaging is required?
   See updates to Section 4.9 and 5.]
   3. Do not support explicit liveliness over the data channel.

   TML is responsible for keeping the control and data communication
   channels up.  It however does not have the authority to decide which
   CE to set up the channels with.  That is outside its control.

   If a FE-CE communication channel goes down or connectivity is lost,
   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.

   TBD: Since  Alternatively, the
     PL layer may detect the channel is unaware of down via the number use of channels etc.,
   what if only one the PL generated
     heartbeat messages.

   If the control channel goes down, but the other is up?  The TML
   layer notifies the PL layer will control initiation of which channel (control/data) is down? a
   failover to a new CE – both control and data channels will be
   reestablished with the new CE.

   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.

   TBD: If an FE goes down and a standby FE exists for it, but it does
   not have communication channels set up with the CE, how should it be
   notified to set up the channels?  This is not within the scope of
   TML itself, but falls in the scope of High Availability.  Do we need
   this mentioned here?

4.9.Encapsulations Used

   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 The PL data messages is dependent on the protocol that will be used for
   carried over the data channel (TCP is only for the control channel). If DCCP is
   used for the data channel, then are encapsulated in a DCCP header will be added.] header.

5.   TML Messaging

   There is no TML layer messaging.  TML only transports messages from
   the PL layer.

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 Service Interface

6.1.1.TML Initialize

   status tmlInit(
     in  channelType,
     in  initAttributes)

   Input Parameters:
     channelType: control versus data channel
     initAttributes: Overview

   This section provides an overview of the TML service interface to
   help with understanding the following sections on protocol behavior
   with respect to initialization parameters

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis: and multicast support.  The details
   on this interface are specified in Appendix A.

   tmlInit() enables – Enables establishment of communication channels on the
   entity that this API is invoked.  Optionally specifies attributes if
   any,

   tmlOpen() – Opens one or more communication channels for initialization. control and
   data messaging

   tmlClose() – Closes one or more communication channels used for
   control and data messaging

   tmlWrite() – Write messages to a specific CE or FE

   tmlRead() – Read messages from a specific CE or FE

   tmlMulticastGroupJoin() – Request an FE to join a multicast group

   tmlMulticastGroupLeave() - Request an FE to leave a multicast group

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 call does not however result in section defines a model for the setup
   of any channels.

   ForCES Usage Model: the channels, using the TML interface defined above. In this
   model, 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 peer TML channels on a per channel type
   basis (control channel versus data channel).  For example, say for
   control messaging, Layers may establish the CE communicates with five FEs using TCP TML control and with another two FEs, using UDP TML.  tmlInit() will need to be
   invoked twice, once for data
   channels between the TCP TML attributes FE and once for the UDP
   TML attributes for CE without the control channel setup with all involvement of the FEs.
   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
   Layers, or if desired, the PL Layer is oblivious of may trigger the number setup 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
   channels; this
   information should is left as an implementation decision.  Both modes
   may also be fed to the TML Layer via some other means. supported within an implementation.

6.2.1.Protocol Initialization

   The CE functions as the server, so the server should control channel must be up and
   running however prior to established between the clients (FEs) coming up FE TML and trying the
   CE TML for establishment of association to
   connect proceed.  This channel
   will be used for messages related to the server (CE). association setup and
   capability query.  The other option is that the mechanism
   to specify attributes for data channel must be established no later
   than the channels is distinct response from the process
   that uses those attributes FE to start up the server.  In that case,
   tmlInit() could be used mainly to start the server.]

6.1.2.TML Channel Open

   status tmlOpen(
     in  elementId,
     in  channelMode,
     in  ctrlChannelAttributes,
     in  dataChannelAttributes,
     in  eventHandlerCallBack)

   Input Parameters:
     elementId: Specific CE for which channel needs to be setup
     channelMode: unicast versus multicast
     ctrlChannelAttributes: control channel establishment parameters
     dataChannelAttributes: data Topology query message.  The
   following are the significant aspects associated with channel establishment parameters
     eventHandlerCallback: Callback function to be invoked on event
   generation

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   tmlOpen() results in one or more setup:
   - A single call by the PL layer sets up the communication channels
     for both control and data messaging being established with the specified elementId. to a specific FE.  The call
     specifies Unicast CE Id and attributes for control and data
     channels.
   - It is up to the TML layer implementation whether to setup set up 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
   channel(s), or if the channel(s) are already established, it only
   results in a registration for the channel(s).  In either case, if
   successful, status is returned to indicate successful
   creation/registration of the control and data channels.  No
   descriptors are returned to
   - TML sets up the PL layer since appropriate channels and allocates required
     descriptors for the channels.  TML layer maintains the a mapping
     between the PL provided elementId Unicast FE/CE Id and the channel descriptors and
     channel type (control versus data) it allocates. If this call triggers creates.
   - There is no need for channel descriptors to be returned to the establishment of PL
     layer at either the control and data channels, FE or the channels are established using CE.  PL Layer only uses the ctrlChannelAttributes Unicast
     FE/CE Id for read/write calls and dataChannelAttributes parameters
   respectively, specified to the call.  Once the channel(s) are setup
   (or if already setup prior to this call), specifies the caller type of this API is
   also capable message
     (control versus data) to be read/written.
   - If only one of receiving TML events via the specified event
   handling callback function. If this call channels is invoked multiple times
   on a channel that has already been opened and registered, a setup successfully, the TML layer
     will have to return appropriate 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, that specifies which functions as the client.
   On each FE, it
     channel is invoked once for both control and data channels
   that the FE wishes to setup with successfully and which isn’t.

   Figure 4 illustrates the CE.

   Notes:
   In initialization model where the case of TCP TML, since there is no inherent support for
   multicast, regardless of PL layer via
   an interface provided by the channelMode specified, TML Layer, triggers the specified
   channel would be setup as a unicast channel; however, of the unicast
   channel would be able to support pseudo multicast.  Hence, TCP TML
   has no need to set up distinct channels for unicast
   control and multicast
   communication; they are both mapped to the same TCP connection.

6.1.3. data channels.

     FE1 PL           FE1 TML Channel Close

   status tmlClose(
     in  elementId,
     in  mode)

   Input Parameters:
     elementId: address of element with which communication channel is
   to be terminated
     mode: mode of operation for the close û forced versus controlled

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   Tears down/terminates communication channels connecting to the
   specified elementId.  This API closes both control and data channels
   (regardless of whether they are implemented as a single channel or
   distinct channels in the TML layer); it is not possible to close
   just one of them.   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 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:
   This API may be invoked by either the CE or the FE.  If the FE PL
   invokes it, it specifies a CE ID for the elementId.  If the          CE PL
   invokes it, it specifies an
           |               |                       |               | \
        /  |               |                       | tmlInit()     | |
   FE ID for the elementId.

6.1.4.TML Channel Write

   status tmlWrite(
     in  elementId,
     in  msgType,
     in  msg,
     in  msgSize,
     in  timeout,
     out bytesWritten)

   Input Parameters:
     elementId: address of element to be written to; may be a unicast,
   multicast or broadcast address
     msgType:   |  |               |                       |<--------------| > CE Init/
 Init/  <  |               |                       |               | | Bootup
 Bootup |  |               |                       |               | /
        \  |               |                       |               |
           | tmlOpen(CeId) |                       |               |
           |-------------->|                       |               | \
           |               |CtrlChan(Cc) Setup     |               | | Setup control versus data message
     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:
   Sends message to the address specified by elementId.  If the
   specified elementId is associated with a multicast group, the
   message will be sent to all members of the group.  Similarly,
           |               |~~~~~~~~~~~~~~~~~~~~~~>|               | | channel if the
   elementId specified is a broadcast address, the message is sent to
   all elements associated with the broadcast address.  The msgType
   parameter is used not
           |               |                FeId . [CcDes<ctrl>]  | | setup. TML
           |               |                       |               | > has mapping
           |               |CtrlChan(Cc) Setup Rsp |               | | from PL Layer
           |               |<~~~~~~~~~~~~~~~~~~~~~~|               | | Id to specify whether the message is a control or channel
           |        CeId . [CcDes<ctrl>]          |               | | descriptor and
           |                                       |               | / channel type.
           |               |                       |               |
           |               |DataChan(Cd) Setup     |               | | Setup data type of message.  Based on the message type, the TML will send
   the message over the appropriate channel.  The
           |               |~~~~~~~~~~~~~~~~~~~~~~>|               | | channel if not
           |               |                FeId . [CcDes<ctrl>,  | | setup. TML layer uses the
   address specified by elementId and the msgType to map
           |               |                         CdDes<data>]  | | updates
           |               |                       |               | > mapping from
           |               |DataChan(Cd) Setup Rsp |               | | PL Layer
           |               |<~~~~~~~~~~~~~~~~~~~~~~|               | | Id to the
   appropriate channel to be used for sending the message.
           |        CeId . [CcDes<ctrl>,          |               | | descriptor and
           |               | CdDes<data>]          |               | / channel type.
           |               |                       |               |
           |  <-- status   |                       |               |
           |               |                       |               |
           |tmlEvent(ChUp) |                       |tmlEvent(ChUp) |
           |<--.--.--.--.--|                       |--.--.--.--.-->|
           |               |                       |               |
           |               |   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 --.--.--> PL : Events/Notifications/Upcalls
 TML ~~~~~~~~> TML: Internal protocol communication

                      Figure 4: Protocol Initialization (Channel Setup)

6.2.2.Protocol Shutdown

The message
   is queued in the appropriate queue for transmission.  Once this call
   returns, control channel teardown must occur only after the message buffer association
teardown has occurred.  The data channel teardown 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 occur no message
   buffer becomes available, the API returns with an error.

   ForCES Usage Model:
   This API may be invoked by either earlier
than the FE association teardown.

The PL or Layer may shutdown control and data channels via invocation of
the CE PL.  If tmlClose() API.  When the FE PL invokes it, it specifies a CE ID for layer shuts down the elementId.  If channels, the
channels are torn down; hence ForCES messaging between the CE PL
   invokes it, it specifies an (unicast/multicast/broadcast) and FE ID for
   the elementId.
   In the case of TCP TML since there is a single channel used for
   unicast, multicast
no longer possible over those channels.  A tmlClose() results in both
control and broadcast messaging, the same channel is used
   for sending messages regardless data channels (regardless of the address specified.  In other
   cases where there whether they are implemented
as a single channel or distinct channels for unicast versus
   multicast, in the channel to be written TML layer) being
shutdown; it is not possible to will differ based on the
   address specified.

6.1.5.TML Channel Read

   status tmlRead(
     in  elementId,
     in  msgType,
     in  msgBuf,
     in  timeout,
     out bytesRead)

   Input Parameters:
     elementId: address close just one of element to be read from; them. A subsequent
tmlOpen() triggers establishment of the channel.  The channel(s) may be a unicast,
   multicast
shutdown by either the FE or broadcast address
     msgType: control versus data message
     msgBuf: buffer into which message is the CE. If an FE initiates the shutdown,
it specifies the CE Id associated with the channel(s) to be read
     timeout: shutdown.
If a CE initiates the shutdown, it 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 from the specified address. The msgType parameter is
   used to specify whether FE Id associated with
the message channel(s) to be read shutdown.  A channel shutdown by the FE is
illustrated in Figure 5 and a control or data
   type of message.  The TML layer uses the address specified by
   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
   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.

   ForCES Usage Model:
   This API may be invoked shutdown by either the CE or the FE.  If the is illustrated
in Figure 6.

        FE PL
   invokes it, it specifies a           FE TML                  CE ID for the elementId.  If the TML          CE PL
   invokes it, it specifies an (unicast/multicast/broadcast)
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               | Config Request        |               |
           |<--------------|-----------------------|---------------|
           |               | Config Response       |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               | Association Teardown  |               |
           |<--------------|-----------------------|---------------|
           |               |                       |               |
           |               |                       |               | \
           |tmlClose(CeId) |                       |               | | FE ID for
   the elementId.

   In the case of TCP initiated:
           |-------------->|                       |               | > FE specifies CE
           | <-- status    |                       |               | | Id associated
           |               |                       |               | / with channel.

Legend:
 PL  --------> PL : Protocol layer messaging
 PL  --------> TML: TML since there is a single channel used for
   unicast, multicast and broadcast messaging, the same channel is used 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
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               | Config Request        |               |
           |<--------------|-----------------------|---------------|
           |               | Config Response       |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               | Association Teardown  |               |
           |<--------------|-----------------------|---------------|
           |               |                       |               |
           |               |                       |               | \
           |               |                       |tmlClose(FeId) | | CE initiated:
           |               |                       |<--------------| > FE specifies CE
           | <-- status    |                       | 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 6: Protocol Shutdown: CE Initiated

6.3.Multicast Model

   The TML layer provides support for reading messages regardless multicast of the address specified. control messages.
   In other
   cases where there are distinct channels for unicast versus
   multicast, the channel ForCES model, support is required to multicast to be read from will differ based on the
   address specified.

6.1.6.TML Multicast Group Join

   status tmlMulticastGroupJoin(
     in  groupId, FEs
   from a CE; in  groupAttributes)

   Input Parameters:
     groupId: address this case, the CE is the source or root of the
   multicast group to join
     groupAttributes: attributes associated with and the FEs are the leaves.

   Support for multicast requires that a channel for supporting
   multicast group to be joined

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:

   Joins opened between an FE and the multicast group specified by groupId as leaf node in CE.  In the
   group. Once a member case of this group, TCP
   TML, the entity calling same channel is used for both unicast and multicast
   messaging since multicast mode is simulated using unicast channels
   in this API will
   be capable of receiving messages addressed case. Once the channel is open, a CE may request FEs to this join
   and leave specified multicast groups.  Multicast support is CE-
   initiated.  FEs can join a multicast group only if the CE requests
   them to join the group.
   The  TML layer on each end (CE/FE) maintains the mapping between the PL layer multicast address
   IDs and the descriptors. channel descriptors for multicast.  The TML layer on
   the element which is the root of the multicast updates the set of
   elements that following are members of the group specified by groupId.

   ForCES Usage Model:
   This API would be invoked on both the CE and the FE.  Initially, the
   intent is to only support FE multicast.  In such
   significant steps for adding or removing members from a case. on the FE
   the API is invoked once the multicast
   group:

   - CE PL layer on the communicates with FE receives a request
   from the PL layer on for requesting the CE FE to join or
     leave a specified multicast group. On
   the CE it is invoked after the
   - FE has successfully joined PL informs FE TML regarding the
   multicast group.

6.1.7.TML Multicast Group Leave

   status tmlMulticastGroupLeave(
     in  groupId)

   Input Parameters:
     groupId: address of multicast group to join or leave

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   Leaves request.
   - FE TML updates the multicast group specified by groupId 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.   The
   TML layer on each end (CE/FE) updates information.  It updates the
     mapping between the PL
   layer multicast address FE Multicast Id and the descriptors.  The TML layer on the
   element which is the root of the channel descriptor to
     be used for multicast updates the set of
   elements for that are members of the group specified by groupId.

   ForCES Usage Model: FE.  This API would mapping may be invoked on both the CE and the FE.  Initially, the
   intent is to only support from
     [Multicast FE multicast.  In such a case, on the Id] . [FE Id] . [Channel descriptor] or directly
     from [Multicast FE
   the API Id] . [Channel descriptor].  This is invoked once the PL layer on the
     implementation dependent.
   - FE receives a request
   from the PL layer on the CE responds to leave a specified multicast group. On
   the CE PL informing it is invoked after of the FE has successfully left status of the
   multicast group.

6.2.Protocol Initialization and Shutdown Model

   In order for join or
     leave request.
   - If the peer join or leave request was successful, CE PL Layers to communicate, the control and data
   channels must be setup.  This section defines a model for the setup
   of informs CE TML
     regarding the channels, using update to the multicast group membership.
   - CE TML interface defined above. In this
   model, updates the peer TML Layers may establish multicast group membership.  It updates the control and data
   channels
     mapping between the FE Multicast Id and the CE without the involvement set of channel
     descriptors to be used for multicast to the PL
   Layers, or if desired, the PL Layer may trigger the setup FEs that are members
     of the
   channels; this is left as an implementation decision.  Both modes group.  This mapping may also be supported within an implementation.

6.2.1.Protocol Initialization

   The control channel must be established between the from [Multicast FE TML and the
   CE TML for establishment Id] . [Set
     of FE Ids] . [Set 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 descriptors] or directly from the
     [Multicast FE to the CE Topology query message.  The
   following are the significant aspects associated with Id] . [Set of 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 descriptors].  This 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.
     implementation dependent.
   - There is no need for channel any descriptors to be returned to the PL
     layer at either the FE or the CE.  PL Layer only uses the Unicast
     FE/CE
     Multicast FE Id for read/write 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 written.

   A tmlWrite() on a unicast FE Id results in a unicast message being
   sent to return appropriate status that specifies which
     channel is setup successfully and which isnÆt.

   Figure 4 illustrates the initialization model where FE associated with the PL layer via
   an interface provided by 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, triggers layer on the setup
   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
   control and data channels. multicast group.

   Multicast Scenario with FE1 joining group: New group created

       FE1 PL        FE1 TML              CE TML           CE PL
         |               |                   |               | \
        /
         |               |                   | TBD:tmlInit()               | \
         |
   FE               MC Grp Join Req (McId)              | |
         |<--------------|-------------------|---------------| |                       |<--------------| > CE Init/
 Init/  < CE:PL Level multicast group
[TML     | tmlJoin(McId) |                   |               | | Bootup
 Bootup join request sent to each
updates  |-------------->|                   |               | | FE:PL that needs to be part
MC grp   |        McId = {FE1_ChDes}         | /
        \               | > of a multicast group, McId,
info]    |               |                   |               | tmlOpen(CeId) | where McId specifies a
         |  <-- status   |
           |-------------->|                   |               | \ |               |CtrlChan(Cc) Setup multicast group Id at the
         |               |                   | Setup control               |               |~~~~~~~~~~~~~~~~~~~~~~>| | PL layer.
         | channel if not              MC Grp Join Rsp (status)             | |                FeId . [CcDes<ctrl>]
         |---------------|-------------------|-------------->| /
         |               | setup. TML                   |               |
         |               | > has mapping                   |               |CtrlChan(Cc) Setup Rsp               | \
         |               | from PL Layer                   |tmlJoin(McId)  |               |<~~~~~~~~~~~~~~~~~~~~~~| | TML updates multicast
         | Id to channel               |        CeId . [CcDes<ctrl>]                   |<--------------| | group membership.  PL is
         |               | descriptor and              McId = {FE1_ChDes}   |                                       |               | / channel type. > only aware of PL layer
         |               |                   |               | |               |DataChan(Cd) Setup     | multicast group Id, that is,
         |               | Setup data                   |               |~~~~~~~~~~~~~~~~~~~~~~>|  status -->   | | channel if not McId]
         |               |                FeId . [CcDes<ctrl>,                   |               | setup. /

                       Figure 7: Multicast Support: FE1 Joins Group

   Multicast Scenario with FE1 leaving group: Group membership updated
   to exclude FE1

        FE1 PL        FE1 TML              CE TML           CE PL
         |               |                         CdDes<data>]                   |               | updates
         |               |                   |               | > mapping from \
         |               |DataChan(Cd) Setup Rsp               MC Grp Leave Req (McId, FE1)        | |
         |<--------------|-------------------|---------------| | PL Layer CE:PL Level multicast group
[TML     |               |<~~~~~~~~~~~~~~~~~~~~~~| tmlLeave(McId)|                   |               | Id to channel |        CeId . [CdDes<data>] leave request sent to FE1:PL
removes  |-------------->|                   |               | | descriptor and that needs to be removed
MC grp   |        McId = {}                  |               | > from multicast group, McId,
info]    | / channel type.               |                   |               | | where McId specifies a
         |  <-- status   |                   |               | | multicast group Id at the
         |               |                   |
           |tmlEvent(ChUp) |                       |tmlEvent(ChUp) |
           |<--.--.--.--.--|                       |--.--.--.--.-->|
           |               |                       |               |
           |               |   Asso Setup Req      |               |
           |---------------|-----------------------|-------------->| | PL layer.
         |   Asso Setup              MC Grp Leave Rsp (status)            | |
           |<--------------|-----------------------|---------------|
           |               |                       |
         |---------------|-------------------|-------------->| /
         |               |                   |    Capability Query               |
         |
           |<--------------|-----------------------|---------------|               |                   | Capability Query Rsp               | \
         |
           |---------------|-----------------------|-------------->|               |                   |tmlLeave(McId) | | TML removes FE1 from
         |               |                   |<--------------| |   Topology Query multicast group McId.
         |               |
           |<--------------|-----------------------|---------------|              McId = {FE2_ChDes}   | > That leaves only FE2
         | Topology Query Rsp               |                   |
           |---------------|-----------------------|-------------->|               | | in the group.
         |               |                   |               |STEADY STATE OPERATION  status -->   | |
           |<--------------|-----------------------|-------------->|
         |               |                   |               |
Legend:
 PL  --------> PL : Protocol layer messaging
 PL  --------> TML: TML API
 TML --.--.--> PL : Events/Notifications/Upcalls
 TML ~~~~~~~~> TML: Internal protocol communication /
                       Figure 4: Protocol Initialization (Channel Setup)

6.2.2.Protocol Shutdown 8: Multicast Support: FE1 Leaves Group

6.4.Broadcast Model

   The TML layer provides support for broadcast of control channel teardown must occur only after messages.
   In the association
teardown has occurred.  The data channel teardown may occur no earlier
than ForCES model, support is required to broadcast to the association teardown. FEs
   from a CE.  The PL Layer may shutdown control and data channels via invocation broadcast model is just a special case of
the tmlClose() API.  When the PL layer shuts down the channels, the
channels multicast,
   where all FEs are torn down; hence ForCES messaging between included.  This TML does not support CE or NE
   broadcast.

7.   Security Considerations

   If the CE and or FE is
no longer possible over those channels.  A tmlClose() results in both
control and data channels (regardless of whether they are implemented
as in a single channel or distinct channels in the TML layer) being
shutdown; box and network operator is running
   under a secured environment then it is not possible up to close just one of them. A subsequent
tmlOpen() triggers establishment the network
   administrator to turn off all the security functions. This is
   configured during the pre-association phase of the channel.  The channel(s) may be
shutdown by either protocol. This
   mode is called “no security” mode of operation.

   When the FE CEs, FEs are running over IP networks or the CE. If in an FE initiates the shutdown,
it specifies insecure
   environment, the CE Id associated with operator has the channel(s) choice of configuring either TLS
   [6] or IPSec [15] to be shutdown.
If a CE initiates provide security. The security association
   between the shutdown, it specifies CEs and FEs MUST be established before any ForCES
   protocol messages are exchanged between the CEs and FEs.

7.1.TLS Usage for Securing TML

   This section is applicable for CE or FE Id associated with endpoints that use the channel(s) TML
   with TLS [6] to be shutdown.  A channel shutdown by the FE secure communication.

   Since CE is
illustrated in Figure 5 master and a channel shutdown by 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 is illustrated
in Figure 6.
   must request certificate from FE PL and FE TML 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. With this TML, TLS is used
   only for the control channel while the data channel is left
   unsecured since the data packets (e.g. routing protocol packets) may
   contain their own security mechanisms. Further, TLS has not yet been
   defined for usage with DCCP.

7.2.IPSec Usage for securing TML
   This section is applicable for CE PL
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               | Config Request        |               |
           |<--------------|-----------------------|---------------|
           |               | Config Response       |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               | Association Teardown  |               |
           |<--------------|-----------------------|---------------|
           |               |                       |               |
           |               |                       |               | \
           |tmlClose(CeId) |                       |               | | FE initiated:
           |-------------->|                       |               | > or FE specifies CE
           | <-- status    |                       |               | | Id associated
           |               |                       |               | / endpoints that use the TML
   with channel.

Legend:
 PL  --------> PL : Protocol IPSec [15] to secure their respective communication. IPSec is
   transparent to the higher-layer applications and can provide
   security for any transport layer messaging
 PL  --------> TML: TML API
 TML --.--.--> PL : Events/Notifications/Upcalls protocol. This mechanism is can be
   used to secure just the control or both the control and the data
   channel simultaneously.

8.   IANA Considerations

   This TML ~~~~~~~~> TML: Internal protocol communication

                       Figure 5: Protocol Shutdown: FE Initiated

        FE PL           FE TML                  CE TML          CE PL
           |               |                       |               |
           |               |STEADY STATE OPERATION |               |
           |<--------------|-----------------------|-------------->|
           |               | Config Request        |               |
           |<--------------|-----------------------|---------------|
           |               | Config Response       |               |
           |---------------|-----------------------|-------------->|
           |               |                       |               |
           |               | Association Teardown  |               |
           |<--------------|-----------------------|---------------|
           |               |                       |               |
           |               |                       |               | \
           |               |                       |tmlClose(FeId) | | CE initiated:
           |               |                       |<--------------| > FE specifies CE
           | <-- status    |                       | 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 6: Protocol Shutdown: CE Initiated

6.3.Multicast Model

   The TML layer provides support needs to have a one well-defined TCP port number for multicast.  In the ForCES model,
   support is required
   control messaging, which needs to multicast be assigned by IANA.  The control
   port is referred to as the FEs from a CE; in this case,
   the CE TCP_TML_CONTROL_PORT.  Similarly, TML
   requires one well-defined DCCP port number for data messaging.  This
   data port is referred to as the source or root of the multicast and the FEs are the
   leaves.

   Support DCCP_TML_DATA_PORT.

9.   Manageability

   TBD

10.    References
10.1.Normative References

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

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

  3. Khosravi, et al., ’’Requirements for supporting
   multicast be opened between an FE and the CE.  In the case Separation of TCP
   TML, the same channel is used for both unicast IP Control and multicast
   messaging since multicast mode is simulated using unicast channels
   in this case. Once the channel is open, a CE may request FEs to join
     Forwarding”, RFC 3654, November 2003.

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

  5.  A. Doria, et al., ”ForCES protocol specification”, draft-ietf-
     forces-protocol-06.txt, December 2005.

10.2.Informative References

  6. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and leave specified multicast groups.  Multicast support is CE-
   initiated.  FEs can join a multicast group only if the CE requests
   them to join the group.  TML maintains mapping between PL layer IDs P.
     Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

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

  8. R. Stewart, et al., “Stream Control Transmission Protocol (SCTP)”,
     RFC 2960, October 2000.

  9. E. Kohler, M. Handley, S. Floyd, J. Padhye, “Datagram Congestion
     Control Protocol (DCCP)”, draft-ietf-dccp-spec-13.txt, December
     2005.

  10.Floyd, S., “Congestion Control Principles”, RFC 2914, September
     2000.

  11.A. Doria, F. Hellstrand, K. Sundell, T. Worster, “General Switch
     Management Protocol (GSMP) V3”, RFC 3292, June 2002.

  12.H. Balakrishnan, et al. “The Congestion Manager”, RFC 3124, June
     2001.

  13.H. Khosravi, S. Lakkavali, “Analysis of protocol design issues for multicast.  The following is the
   significant steps
     open standards based programmable routers and switches” [SoftCOM
     2004]

  14.S. Lakkavali, H. Khosravi, “ForCES protocol design analysis for adding or removing members from a multicast
   group:

   - CE PL communicates with FE PL
     protection against DoS attacks” [ICCCN 2004]

  15.S. Kent, R. Atkinson, “Security Architecture for requesting the FE to join or
     leave a multicast group.
   - FE PL informs FE TML regarding the join or leave request.
   - FE Internet
     Protocol”, RFC 2401

11.    Acknowledgments

Appendix A. TML updates the multicast group information.  It updates the
     mapping between the FE Multicast Id and the Service Interface

A.1. TML Initialize

   status tmlInit(
     in  channelType,
     in  initAttributes)

   Input Parameters:
     channelType: control versus data channel descriptor to
     be used for multicast for
     initAttributes: initialization parameters

   Output Parameters:

     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   tmlInit() enables establishment of communication channels on the
   entity that FE.  This mapping may be from
     [Multicast FE Id] . [FE Id] . [Channel descriptor] or directly
     from [Multicast FE Id] . [Channel descriptor].  This this API is
     implementation dependent.
   - FE PL responds to CE PL informing it of invoked.  Optionally specifies attributes if
   any, for initialization. This call does not however result in the status
   setup of any channels.

   ForCES Usage Model:
   In the join or
     leave request.
   - If case of ForCES which follows a client-server model, this API
   would be invoked on the join or leave request was successful, CE PL informs CETML
     regarding CE, which functions as the update to 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 multicast group membership.
   - CE communicates with five FEs using TCP TML updates the multicast group membership.  It updates the
     mapping between the FE Multicast Id
   and the set of channel
     descriptors with another two FEs, using UDP TML.  tmlInit() will need to be used
   invoked twice, once 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 TCP TML attributes and once for any descriptors to be returned to the PL
     layer at either the FE or UDP
   TML attributes for the CE.  PL Layer only uses control channel setup with all of the
     Multicast FE Id FEs.
   The same holds true for write calls and specifies the type of message
     (control versus data) data channel setup in the above case.

A.2. TML Channel Open

   status tmlOpen(
     in  elementId,
     in  channelMode,
     in  ctrlChannelAttributes,
     in  dataChannelAttributes,
     in  eventHandlerCallBack)

   Input Parameters:
     elementId: Specific CE for which channel needs to be written.

   A tmlWrite() on a unicast FE Id results in a setup
     channelMode: unicast message being
   sent versus multicast
     ctrlChannelAttributes: control channel establishment parameters
     dataChannelAttributes: data channel establishment parameters
     eventHandlerCallback: Callback function to the FE associated with the channel.  A tmlWrite() be invoked on a
   multicast FE Id event
   generation

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD
   Synopsis:
   tmlOpen() results in multicast messaging. Figures 7 one or more communication channels for control
   and 8
   illustrate multicast scenarios data messaging being established 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 specified elementId.
   It is up 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 implementation whether to include FE2 in the group.  In Figure 8, 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 CE requests FE1 to
   leave establishment of the multicast group, thus resulting in
   channel(s), or if the channel(s) are already established, it only FE2 being
   results in a member registration for the channel(s).  In either case, if
   successful, status is returned to indicate successful
   creation/registration of the multicast group.

   Multicast Scenario with FE1 joining group: New group created

       FE1 control and data channels.  No
   descriptors are returned to the PL        FE1 TML              CE layer since the TML           CE layer
   maintains the mapping between the PL
         |               |                   |               |
         |               |                   |               | \
         |               MC Grp Join Req (McId)              | |
         |<--------------|-------------------|---------------| | CE:PL Level multicast group
[TML     | tmlJoin(McId) |                   |               | | join request sent provided elementId and the
   descriptors it allocates. If this call triggers the establishment of
   the control and data channels, the channels are established using
   the ctrlChannelAttributes and dataChannelAttributes parameters
   respectively, specified to each
updates  |-------------->|                   |               | | FE:PL that needs the call.  Once the channel(s) are setup
   (or if already setup prior to be part
MC grp   |        McId = {FE1_ChDes}         |               | > 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 multicast group, McId,
info]    |               |                   |               | | where McId specifies channel that has already been opened and registered, a
         |  <-- return
   status   |                   |               | | multicast group Id at of ALREADY_REGISTERED is returned, with no change to
   registration.

   ForCES Usage Model:
   In the
         |               |                   |               | | PL layer.
         |              MC Grp Join Rsp (status)             | |
         |---------------|-------------------|-------------->| /
         |               |                   |               |
         |               |                   |               | \
         |               |                   |tmlJoin(McId)  | | 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 for both control and data channels
   that the FE wishes to setup with the CE.

   Notes:
   In the case of TCP TML updates multicast
         |               |                   |<--------------| | group membership.  PL for the control channel, since there is
         |               |              McId = {FE1_ChDes}   | > only aware no
   inherent support for multicast, regardless of PL layer
         |               |                   |               | | 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, TCP TML has no need to set up distinct
   channels for unicast and multicast group Id, that is,
         |               |                   |  status -->   | | McId]
          |               |                   |               | /

                       Figure 7: Multicast Support: FE1 Joins Group

   Multicast Scenario with FE1 leaving group: Group membership updated communication; they are both
   mapped to exclude FE1

        FE1 PL        FE1 the same TCP connection.

   In the case of DCCP TML              CE for the data channel, multicast mode is not
   being supported.  Hence, channelMode would be ignored.

A.3. TML           CE PL
         |               |                   |               |
         |               |                   |               | \
         |               MC Grp Leave Req (McId, FE1)        | |
         |<--------------|-------------------|---------------| | CE:PL Level multicast group
[TML     | tmlLeave(McId)|                   |               | | leave request sent to FE1:PL
removes  |-------------->|                   |               | | that needs to be removed
MC grp   |        McId = {}                  |               | > from multicast group, McId,
info]    |               |                   |               | | where McId specifies a
         |  <-- Channel Close

   status   |                   |               | | multicast group Id at the
         |               |                   |               | | PL layer.
         |              MC Grp Leave Rsp (status)            | |
         |---------------|-------------------|-------------->| /
         |               |                   |               |
         |               |                   |               | \
         |               |                   |tmlLeave(McId) | | TML removes FE1 from
         |               |                   |<--------------| | multicast group McId.
         |               |              McId = {FE2_ChDes}   | > That leaves only FE2
         |               |                   |               | | tmlClose(
     in the group.
         |               |                   |  status -->   | |
         |               |                   |               | /

                       Figure 8: Multicast Support: FE1 Leaves Group

6.4.Broadcast Model

   The TML layer provides support for broadcast.  In the ForCES model,
   support  elementId,
     in  mode)
   Input Parameters:
     elementId: address of element with which communication channel is required
   to broadcast be terminated
     mode: mode of operation for the close – forced versus controlled

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   Tears down/terminates communication channels connecting to the FEs from
   specified elementId.  This API closes both control and data channels
   (regardless of whether they are implemented as a CE.  The
   broadcast model single channel or
   distinct channels in the TML layer); it is not possible to close
   just a special case one 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

   If the them.   No further CE or PL – FE are in a single box and network operator is running
   under a secured environment then it PL messaging is up to the network
   administrator to turn off all possible
   after this.  If the security functions. This mode is
   configured during the pre-association phase of the protocol.

   When the CEs, FEs specified as controlled, current
   messages that are running over IP networks or pending in an insecure
   environment, this TML uses TLS [8] to provide security. The security
   association between the CEs and FEs MUST TML layer shall be established before any
   ForCES protocol sent, but no new
   messages are exchanged between shall be accepted by the CEs and FEs.

7.1.TLS Usage for this TML
   [TBD: Update based layer on inclusion of IPSec for security.]

   This section is applicable for CE or FE endpoints that use this channel.  In the
   forced mode, messages pending in the TML
   with TLS [8] to secure communication. layer shall be discarded.
   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 channel was terminated, a subsequent tmlOpen() will
   trigger establishment process. CE
   must request certificate from FE and FE needs to pass of the channel.

   ForCES Usage Model:
   This API may be invoked by either the requested
   information.

   We recommend ôTLS-RSA-with-AES-128-CBC-SHAö cipher suite, but CE or the FE.  If the FE may negotiate other TLS cipher suites. TLS must be used PL
   invokes it, it specifies a CE ID for all
   control channel messages. TLS is optional the elementId.  If the CE PL
   invokes it, it specifies an FE ID for the elementId.

A.4. TML Channel Write

   status tmlWrite(
     in  elementId,
     in  msgType,
     in  msg,
     in  msgSize,
     in  timeout,
     out bytesWritten)

   Input Parameters:
     elementId: address of element to be written to; may be a unicast,
   multicast or broadcast address
     msgType: control versus data channel since
   data channel packets are not encrypted externally message
     msg: message to the NE.

   This TML uses TLS be sent
     msgSize: size of message 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 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:
   Sends message to the application
   and use of Port identifiers address specified by elementId.  If the
   specified elementId is prohibited within IKE Phase 1. This
   provides restriction for IPsec associated with a multicast group, the
   message will be sent to configure trust anchors for each
   application separately and policy configuration is common for all
   applications.

8.   IANA Considerations

   The TCP/IP TML needs to have members of the group.  Similarly, if the
   elementId specified is a one well-defined TCP port number,
   which needs broadcast address, the message is sent to be assigned by IANA.
   all elements associated with the broadcast address.  The control port msgType
   parameter is referred used to
   as specify whether the TCP_TML_CONTROL_PORT.  [TBD: Add information for message is a control or
   data channel
   port if required based type of message.  Based on the protocol for message type, the data channel.]

9.   Manageability

   TBD

10.    References
10.1.Normative References

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

  2. S. Bradner, "Keywords TML will send
   the message over the appropriate channel.  The TML layer uses the
   address specified by elementId and the msgType to map to the
   appropriate channel to be used for use sending the message.  The message
   is queued in RFCs 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 Indicate Requirement
     Levels", RFC2119 (BCP), IETF, March 1997.

  3. Khosravi, et al., öRequirements 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.  If the FE
   PL invokes it, it specifies a CE ID for Separation the elementId.  If the CE PL
   invokes it, it specifies an (unicast/multicast/broadcast) FE ID for
   the elementId.
   In the case of IP Control TCP TML since there is a single channel used for
   unicast, multicast 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 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.

A.5. TML Channel Read

   status tmlRead(
     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.

10.2.Informative References

  8. Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.  elementId,
     in  msgType,
     in  msgBuf,
     in  timeout,
     out bytesRead)

   Input Parameters:
     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
     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 from the specified address. The msgType parameter is
   used to specify whether the message to be read is a control or data
   type of message.  The TML layer uses the address specified by
   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
   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.

   ForCES Usage Model:
   This API may be invoked by either the CE or the FE.  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 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.

A.6. TML Multicast Group Join
   status tmlMulticastGroupJoin(
     in  groupId,
     in  groupAttributes)

   Input Parameters:
     groupId: address of multicast group to join
     groupAttributes: attributes associated with the multicast group to
   be joined

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD

   Synopsis:
   Joins the multicast group specified by groupId as leaf node in the
   group. Once a member of this group, the entity calling this API will
   be capable of receiving messages addressed to this multicast group.
   The TML layer on each end (CE/FE) maintains the mapping between the
   PL layer multicast address and P.
     Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

  9. Jungmaier, A., Rescorla, E. 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:
   This API would be invoked on both the CE and the FE.  Initially, the
   intent is to only support FE multicast.  In such a case. on the FE
   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.

A.7. TML Multicast Group Leave

   status tmlMulticastGroupLeave(
     in  groupId)

   Input Parameters:
     groupId: address of multicast group to leave

   Output Parameters:
     none

   Returns:
     status: SUCCESS
             Errors TBD
   Synopsis:
   Leaves the multicast group specified by groupId 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.   The
   TML layer on each end (CE/FE) updates the mapping between the PL
   layer multicast address and M. Tuexen, "Transport Layer
     Security over Stream Control Transmission Protocol", RFC 3436,
     December 2002.

  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 the descriptors.  The TML layer on the
   element which is the root of protocol design issues
     for open standards based programmable routers the multicast updates the set of
   elements that are members of the group specified by groupId.

   ForCES Usage Model:
   This API would be invoked on both the CE and switchesö
     [SoftCOM 2004]

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

11.    Acknowledgments

12. the FE.  Initially, the
   intent is to only support FE multicast.  In such a case, on the FE
   the API is invoked once the PL layer on the FE receives a request
   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.

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
   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). (2006).  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.