Internet DRAFT - draft-audu-forces-iptml

draft-audu-forces-iptml



FORCES                                                           A. Audu
Internet-Draft                                                   Alcatel
Expires: April 21, 2005                                    J. Hadi Salim
                                                           Zynx Networks
                                                                A. Doria
                                                                    ETRI
                                                        October 21, 2004



  Forwarding and Control Element Separation IP Transport Mapping Layer
                       draft-audu-forces-iptml-00


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.                                                         


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on April 21, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).











Audu, et al.             Expires April 21, 2005                 [Page 1]
Internet-Draft                ForCES-IPTML                  October 2004



1.  Terminology


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119]


Abstract


   This document defines the Forces-IPTML protocol that is designed to
   complement ForCES-PL (ForCES Protocol Layer) for communicating
   between Forwarding and Control Elements that make up a
   ForCEs-compliant network element, using IP transport technology (e.g.
   TCP/IP, SCTP/IP, UDP/IP).  This protocol addresses all the
   requirements described in the Forces [0] requirements document.  This
   document also specifies architectural attributes necessary in an
   implementation of Forces-IPTML to ensure correct and secure protocol
   operation.



































Audu, et al.             Expires April 21, 2005                 [Page 2]
Internet-Draft                ForCES-IPTML                  October 2004



Table of Contents


   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2


   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5


   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  6


   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
     4.1   Interconnect Encapsulation . . . . . . . . . . . . . . . .  9
     4.2   Reliability  . . . . . . . . . . . . . . . . . . . . . . .  9
     4.3   Fail-Over Model  . . . . . . . . . . . . . . . . . . . . . 10


   5.  ForCES-TML Message Overview  . . . . . . . . . . . . . . . . . 12
     5.1   Protocol Message Header Structure  . . . . . . . . . . . . 12
       5.1.1   Version  . . . . . . . . . . . . . . . . . . . . . . . 12
       5.1.2   eType  . . . . . . . . . . . . . . . . . . . . . . . . 12
       5.1.3   Prio . . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.1.4   Message Classes and Types  . . . . . . . . . . . . . . 13
       5.1.5   Length . . . . . . . . . . . . . . . . . . . . . . . . 15
       5.1.6   Element Tag  . . . . . . . . . . . . . . . . . . . . . 15
       5.1.7   Source Tag . . . . . . . . . . . . . . . . . . . . . . 16
       5.1.8   Destination Tag  . . . . . . . . . . . . . . . . . . . 16
       5.1.9   Transaction Sequence Number  . . . . . . . . . . . . . 16
     5.2   Service Data or Payload Structure  . . . . . . . . . . . . 16
     5.3   ForCES-TML Messages  . . . . . . . . . . . . . . . . . . . 17
       5.3.1   Association and Connection . . . . . . . . . . . . . . 17
         5.3.1.1   Join Request . . . . . . . . . . . . . . . . . . . 17
         5.3.1.2   Join Response  . . . . . . . . . . . . . . . . . . 19
         5.3.1.3   Leave Request  . . . . . . . . . . . . . . . . . . 20
         5.3.1.4   Leave Response . . . . . . . . . . . . . . . . . . 21
         5.3.1.5   Join Multicast Address Request . . . . . . . . . . 21
         5.3.1.6   Join Multicast Address Respone . . . . . . . . . . 22
         5.3.1.7   Leave Multicast Address Request  . . . . . . . . . 23
         5.3.1.8   Leave Multicast Address Response . . . . . . . . . 24
       5.3.2   Primitive Transfer Messages  . . . . . . . . . . . . . 25
         5.3.2.1   Reliable Data Transfer Request . . . . . . . . . . 25
         5.3.2.2   Reliable Data Transfer Resposne  . . . . . . . . . 25
         5.3.2.3   Unreliable Data Transfer Request . . . . . . . . . 25
         5.3.2.4   Unreliable Data Transfer Respone . . . . . . . . . 26
       5.3.3   Security Association . . . . . . . . . . . . . . . . . 26
       5.3.4   Management and Maintenance Messages  . . . . . . . . . 26
         5.3.4.1   Error Reporting  . . . . . . . . . . . . . . . . . 26
         5.3.4.2   HeartBeat Request  . . . . . . . . . . . . . . . . 27
         5.3.4.3   HeartBeat Acknowledge  . . . . . . . . . . . . . . 27
       5.3.5   Event Notification . . . . . . . . . . . . . . . . . . 27
         5.3.5.1   Asunchronous Events Notification . . . . . . . . . 28
       5.3.6   Vendor Specific Extensions . . . . . . . . . . . . . . 28




Audu, et al.             Expires April 21, 2005                 [Page 3]
Internet-Draft                ForCES-IPTML                  October 2004



         5.3.6.1   Vendor Specific Data Request . . . . . . . . . . . 28
         5.3.6.2   Vendor Specific Data Response  . . . . . . . . . . 29
       5.3.7   ForCES-TML Interfaces  . . . . . . . . . . . . . . . . 29
         5.3.7.1   ULP-to-TML Interface . . . . . . . . . . . . . . . 29
         5.3.7.2   TML-to-ULP Interface . . . . . . . . . . . . . . . 31
       5.3.8   Scenarios  . . . . . . . . . . . . . . . . . . . . . . 32
       5.3.9   Security Considerations  . . . . . . . . . . . . . . . 32
       5.3.10  IANA Considerations  . . . . . . . . . . . . . . . . . 32


   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   6.1   Normative References . . . . . . . . . . . . . . . . . . . . 33
   6.2   Non-Normative References . . . . . . . . . . . . . . . . . . 33


       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33


   A.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 35


       Intellectual Property and Copyright Statements . . . . . . . . 36


































Audu, et al.             Expires April 21, 2005                 [Page 4]
Internet-Draft                ForCES-IPTML                  October 2004



2.  Introduction


   Network Elements (NE) such as routers are becoming more and more
   complex as they try to cope with demanding features like policy based
   routing, firewalls and NATs, and QoS aware routing.  As a result,
   issues like scalability, (the ability to cost-effectively grow a
   network as demand increases) and programmability (the ability to
   dynamically program the network for some specific services by
   programming the NEs that handle those services) become very
   important.  The ForCEs protocol has been specified to help resolve
   these issues by decoupling control and forwarding parts of a network
   element, and also adding programmability features to the NE.


   It is also important for the ForCES protocol to run over varying
   transport media.  To this end, ForCES has been split into two layers:
   the Protocol Layer (PL) and the Transport Mapping Layer (TML).  The
   PL is generic and common to all implementations of ForCES and is
   standardized by this IETF document.  The TML is defined in other
   documents.  There is a TML generated per transport medium.  The
   default TML is the IP-TML  that corresponds to a TCP/IP transport
   medium.  The (PL) sits on top of (and receives services from) the
   (TML).  This document specifies the ForCES-IPTML layer.


   Forces-PL has been designed for use in a redundant environment, for
   relaying messages between control elements (CE) and forwarding
   elements (FE) distributed in a network as found in ForCEs.
   ForCES-IPTML will make the interaction between CEs and FEs as
   transparent as possible.
























Audu, et al.             Expires April 21, 2005                 [Page 5]
Internet-Draft                ForCES-IPTML                  October 2004



3.  Definitions


   The following definitions are taken from [FORCES-REQ][RFC3654], and
   [FE-MODEL][I-D.ietf-forces-model]
   Forwarding Element (FE): - A logical entity that implements the
      ForCES protocol.  FEs use the underlying hardware to provide
      per-packet processing and handling as directed by a CE via the
      ForCES protocol.  FEs may use PFE partitions, whole PFEs, or
      multiple PFEs.
   Control Element (CE): - A logical entity that implements the ForCES
      protocol and uses it to instruct one or more FEs how to process
      packets.  CEs handle functionality such as the execution of
      control and signaling protocols.
   Pre-association Phase: - The period of time during which a FE Manager
      (see below) and a CE Manager (see below) are determining which FE
      and CE should be part of the same network element and delivering
      that information to the FE and CE.
   Post-association Phase: - The period of time during which a FE has
      the information specifying what CE is to control it and vice
      versa, including the time during which the CE and FE are
      establishing communication with one another.
   ForCES Post-Association Phase Protocol: - The protocol used for
      post-association phase communication between CEs and FEs.  This
      protocol does not apply to CE-to-CE communication, FE-to-FE
      communication, or to communication between FE and CE managers.
      The ForCES protocol is a master-slave protocol in which FEs are
      slaves and CEs are masters.  This protocol includes both the
      management of the communication channel (e.g., connection
      establishment, heartbeats) and the control messages themselves.
      The term ForCES protocol may refer to a suite of protocols that
      are used to exchange control information as well as redirect data
      packets between the CEs and FEs.
   FE Manager: - A logical entity that operates in the pre-association
      phase and is responsible for determining with which CE(s) an FE
      should communicate.  This process is called CE discovery and may
      involve the FE manager learning the capabilities of available CEs.
      A FE manager may use anything from a static configuration to a
      pre-association phase protocol (see below) to determine which
      CE(s) to use.  Being a logical entity, an FE manager might be
      physically combined with any of the other logical entities
      mentioned in this section.
   CE Manager: - A logical entity that operates in the pre-association
      phase and is responsible for determining with which FE(s) a CE
      should communicate.  This process is called FE discovery and may
      involve the CE manager learning the capabilities of available FEs.
      A CE manager may use anything from a static configuration to a
      pre-association phase protocol (see below) to determine which FE
      to use.  Being a logical entity, a CE manager might be physically




Audu, et al.             Expires April 21, 2005                 [Page 6]
Internet-Draft                ForCES-IPTML                  October 2004



      combined with any of the other logical entities mentioned in this
      section.
   Pre-association Phase Protocol: - A protocol between FE managers and
      CE managers that is used to determine which CEs or FEs to use.  A
      pre-association phase protocol may include a CE and/or FE
      capability discovery mechanism.  Note that this capability
      discovery process is wholly separate from (and does not replace)
      that used within the ForCES protocol.  However, the two capability
      discovery mechanisms may utilize the same FE model.
   ForCES Network Element (NE): - An entity composed of one or more CEs
      and one or more FEs.  To entities outside a NE, the NE represents
      a single point of management.  Similarly, a NE usually hides its
      internal organization from external entities.
   ForCES Protocol Element (PE): - A Forwarding Element or a Control
      Element that speaks the ForCES protocol.
   LFB (Logical Function Block) class (or type): -- A generic template
      representing a fine-grained, logically separable and well-defined
      packet processing operation in the datapath.  LFB class is the
      basic building block of the FE model.
   FE Model (FEM): - Modeling/Organization of LFBs in the Forwarding
      plane.
   CE-TML: - Transport Mapping Layer resident in the control element.
   FE-TML: - Transport Mapping Layer resident in the forwarding element.
   ULP: - Upper Layer Protocol.  Refers to the protocols using the TML
      layer.  These will be the ForCES-PL in the CE and the FE.



























Audu, et al.             Expires April 21, 2005                 [Page 7]
Internet-Draft                ForCES-IPTML                  October 2004



4.  Protocol Overview


   ForCES is a framework consisting of set of protocols representing the
   forwarding and control elements in the form of an extensible model
   [FRAMEWK][FE-MODEL].  CEs handle control, signaling and management
   protocols, while FEs perform forwarding functions.  CEs control the
   behavior of FEs in a master/slave fashion.


   To handle the transport of data and control between the CEs and FEs,
   ForCES has specified two protocol entities: ForCES-Protocol Layer
   (Froces-PL) and the Transport Mapping Layer (Forces-TML).  The
   ForCES-PL is independent of the transport interconnect type, but it
   requires service from the ForCES-TML to communicate with its peer.


   ForCES-PL and ForCES-TML Connecting CEs and FEs



                        +-----------+
                        | Forces-PL |  CE
                        |           |
                        +-----------+
                        |   TML     |  Control Plane
                        +-----------+
                         | | | | | |
              uw1        | | | | | |
         +---------------+ | | | | +---------------+
         |  +-uw2----------+ | | +--------------+  |
         |  |                | |                |  |
         |  |  +--mw1--------+-|--------------+ |  |
         |  |  |               |              | |  |
         |  |  | +--mw2--------+------------+ | |  |
         |  |  | |                          | | |  |
      +-----------+                        +-----------+
      |   TML     |                        |   TML     |
      +-----------+     . . .   ..         +-----------+  Forwarding
      | Forces-PL |                        | Forces-PL |   Plane
      +-----------+                        +-----------+
          FE1                                    FEN


      Legend:   Forces-PL - Protocol Layer
                TML       - Transport Mapping Layer
                uwi       - unicast wire with priority i
                uwj       - unicast wire with priority j
                mwk       - multicast wire with priority k
                mwl       - multicast wire with priority l







Audu, et al.             Expires April 21, 2005                 [Page 8]
Internet-Draft                ForCES-IPTML                  October 2004



                                Figure 1


   In Figure 1, virtual wires or links connect a CE in the control plane
   to a set of FEs (FE1 to FEN)  in the forwardding plane.  There are
   two types of links : unicast and multicast.  Unicast links carry
   unicast data or control between endpoints.  Multicast links carry
   point-to-multipoint data or control.  Each link can be assigned a
   priority.


   The links could be of different quality of service (e.g.  reliable,
   or unreliable), but they are all congestion aware.  This allows the
   protocol to separate control and data traffic into different streams,
   to reduce the threat of Denial of Service (DoS) attacks on the
   survivability of the system and making the protocol more robust.


   In a redundant system, CE s and FE s will be replicated, with one set
   being active at a particular time while the other is in standby.


   The TML provides the following services to the forces-pl:
      reliable service and unreliable service
      security (including end-point authentication, message
      authentication, confidentiality)
      Congestion control
      Unicast, multi-cast, and broadcast
      Timeliness (?)
      Redundancy (?)
      Stream prioritization (?)


   The ForCES-TML  protocol also supports a notion of distributed IPC
   mechanism by providing services required for replication, high
   availability and fail-over (redundancy) to the ForCES-PL in a
   distributed network element environment.


4.1  Interconnect Encapsulation


   The Forces-PL protocol is independent of the Interconnect Layer.  It
   makes no assumptions about the interconnect layer and uses
   interconnect independent addressing  in its common header and API.
   All interconnect specific properties are encapsulated by the TML.


4.2  Reliability


   Separate Control and Data channels


   The ForCES NEs are subject to Denial of Service (DoS) attacks
   [FORCES-REQ, Section 7 #15].  A malicious system in the network can
   flood a ForCES NE with bogus control packets such as spurious RIP or
   OSPF packets in an attempt to disrupt the operation of and the




Audu, et al.             Expires April 21, 2005                 [Page 9]
Internet-Draft                ForCES-IPTML                  October 2004



   communication between the CEs and FEs.  In order to protect against
   this situation, the ForCES protocol uses separate control and data
   channels for communication between the CEs and FEs.


   The data channel carries the control protocol packets such as RIP,
   OSPF messages as outlined in [FORCES-REQ] Section 7 #10, between the
   CEs and FEs.  The other Forces-PL messages, which are used for
   configuration/capability exchanges, event notification, etc, are
   carried over the control channel.  It may be necessary for the data
   channel to be set up as an unreliable but congestion aware channel.


   The control channel is set up as a reliable channel.  The channels
   are set up via the use of the Join process (see section 5.1.1).


   Each channel has a priority value attached to it.  This is used to
   give preferential treatment to the traffic carried on the channels.
   For example, OSPF packets (encoded as  PE Traffic Maintenance
   messages) could be given higher priority than ping packets on the
   data channel.  The use of separate control and data channels, channel
   priority along with rate limiting mechanisms on the FE provides
   robustness to the Forces-PL protocol against DoS attacks.


4.3  Fail-Over Model


   The Forces-PL protocol provides CE fail-over functions in order to
   support high availability of the network element [RFC3654].  The
   CE-SET (see section 4.1.4) is a list of CEs that reside within a
   Network Element (NE) as a cooperating unit.  Likewise, the FE-SET is
   a list of FEs that reside in an NE as a cooperating unit.  The
   following are the high-availability mechanisms that are provided by
   Forces-PL protocol.
   Strong Consistency: In strong consistency mode, the FE sends all
      asynchronous notifications/ control protocol packets to the
      primary and backup CEs in the CE set.  By doing this, the FE
      enables both the primary and backup CEs to keep the state
      synchronized.
   Weak Consistency (Fail-over): In this mode, the FE communicates
      directly with the primary CE.  If the primary CE fails, the FE
      starts communicating with the backup CE.  In an active-standby
      redundant setting, the first CE to be active will be the primary
      CE, while the other will be in standby mode.  Also in a replicated
      FE set, the first set of FEs to be activated will be the primary
      set.


   In all the above cases, CE (including primary and backup CEs) and FEs
   are pre-configured to perform such activities as part of
   pre-association phase.  Also, the TML does not assign different
   treatment status to the links used by primary or backup CEs or FEs




Audu, et al.             Expires April 21, 2005                [Page 10]
Internet-Draft                ForCES-IPTML                  October 2004



   other than the priorities assigned to the links during association.
   In other words, primary or standby roles are not determined by the
   TML.

















































Audu, et al.             Expires April 21, 2005                [Page 11]
Internet-Draft                ForCES-IPTML                  October 2004



5.  ForCES-TML Message Overview


   Forces-TML protocol messages are made up of two parts: the common
   header, and the message body or service payload part.  This section
   describes the details of the common header and payload structure.
   These messages are used to communicate between TML protocol peers and
   are sent network Byte Ordered across the network.


5.1  Protocol Message Header Structure


   Forces-PL protocol Header is fixed size and contains the following
   fields.


   Forces TML Protocol Message Header



           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |vers   |eType  | prio| reservd |  msgClass     |   msgType     |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                       message length                          |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                          Source-Tag                           |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                        Destination-Tag                        |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |                        Sequence Number                        |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                Figure 2



5.1.1  Version


   The version field (4-bits) contains the version of the Forces-PL
   protocol supported by the implementation.  The current supported
   version is : value 0x01 Protocol elements implementing the Forces-TML
   protocol SHOULD provide backwards compatibility with prior versions
   of the protocol.


5.1.2  eType


   This field identifies the format of data exchange used between the
   communicating endpoints.  Valid values include: Value        Description .
   0x1  Plain TLV 0x2       XML 0x3       BINARY-XML




Audu, et al.             Expires April 21, 2005                [Page 12]
Internet-Draft                ForCES-IPTML                  October 2004



5.1.3  Prio


   This three bit field allows eight(8) different levels of priority to
   be assigned to different packet streams.  This enables the different
   packet streams to be given preferential treatments based on the
   priority.  The default setting is 0 (for normal priority)


5.1.4  Message Classes and Types


   Forces-TML's messages are grouped into five (6) classes namely:
      Management Messages used for initializing TML layer, and
      monitoring its status.
      Connection and Association messages, which help establish logical
      connections between FE-TMLs and CE-TMLs.
      Security Association messages, used for authenticating user
      endpoints.
      Boundary Primitive Transport Messages are used by FPL to send and
      receive messages from its peer opaquely via the TML layer.
      Event Handling messages are used to report asynchronous events.
      Application and Vendor Specific messages which are used to
      exchange TML-application data between CE-TML and FE-TML
      application endpoints.  They are used to extend the protocol
      beyond its current capabilities.


   Each class consists of a set of related message types.  The valid
   message classes are:


   Message Class: 8 bits (unsigned integer)



      0         TML Management messages
      1         Connection and association  (CA) Messages
      2         Security Association (SA) Messages
      3         Boundary Primitive Transport (PT) Messages
      4         Event Handling (EH) Messages
      5         Application and Vendor Specific (AV) Messages


      6- 255    Reserved by IETF for future use



   The message types (5 bits) for the defined message classes are as
   follows:


   Message Type for Management ( TM ) Message Class



      0      Reserved
      1      Initialize/Reset Request




Audu, et al.             Expires April 21, 2005                [Page 13]
Internet-Draft                ForCES-IPTML                  October 2004



      2      Initialize/Reset Response
      3              Shutdown Request
      4         Shutdown Response
      5         Status Request
      6         Status Response
      7         Heartbeat
      8         Heartbeat Ack



      9-255    Reserved by IETF for future use



   Message Type for Connection and Association (CA) Message Class



      0      Reserved
      1      Join  Request
      2      Join  Response
      3      Leave Request
      4      Leave Response
      5   Join  MCastAddr Request
      6      Join  MCastAddr Response
      7      Leave MCastAddr Request
      8      Leave MCastAddr Response


     9-255   Reserved by IETF for future use



   Message Types for Primitive Transfer Messages (PT) Message Class



      0      Reserved
      1      Data Request Reliable Message
      2      Data Response Reliable  Message
      3   Data Request Unreliable Message
      4   Data Response Unreliable Message



      5-255  Reserved by IETF for future use



   Message Types for Security Association (SA) Message Class



      0      Reserved
      1      Authentication Request
      2      Authentication Response
      3




Audu, et al.             Expires April 21, 2005                [Page 14]
Internet-Draft                ForCES-IPTML                  October 2004



      4-255  Reserved for future use by IETF



   Message Types for Application and Vendor Specific (AV) Message Class



      0      Reserved
      1      AV-Data Request
      2      AV-Data Response


      3-255  Reserved for other vendor specific messages




5.1.5  Length


   This denotes the length of the message in octets, including the
   message header part.


5.1.6  Element Tag


   This is used to identity a CE or an FE element in the NE for the
   purpose of exchanging data within the system.  It is made up of a SET
   number (identifying the group or set the source element belongs to),
   and a unique Identifier of that element in the set.  Thus for a CE or
   FE, the Element-Tag would look like the following:


   Showing Element Tags for CE and FE



           0                            31
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       a)       | CE-Set Number | CE-Identifier |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      b)        | FE-Set Number | FE-Identifier |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                Figure 3


   During the pre-association phase, the CEs and FEs are configured by
   the CE-Manager and FE-Manager respectively into groups or sets.  A
   group can contain one or more elements, and it is identified by a
   group number (CE-SET or FE-SET number).  Any element within a group




Audu, et al.             Expires April 21, 2005                [Page 15]
Internet-Draft                ForCES-IPTML                  October 2004



   also has a number to identify it.  The combination of this identifier
   and the set number is the element-tag number.


5.1.7  Source Tag


   This denotes the element-tag of the source of the message being
   exchanged between a communicating CE and FE peer.


5.1.8  Destination Tag


   This denotes the element-tag of the destination or sink of the
   message being exchanged between a communicating CE and FE peer.


5.1.9  Transaction Sequence Number


   This 32-bit field uniquely identifies a transaction between an FE-TML
   and a CE-TML.  When a TML endpoint makes a request it generates a TSN
   for use in the request message; the other endpoint copies this same
   TSN number in its reply message.


5.2  Service Data or Payload Structure


   Forces-TML protocol messages consist of the Common Message Header
   described in the previous section, followed by zero or more variable
   length parameters, as defined by the message type.  This constitutes
   the Payload or Service Data.  All Forces-TML messages are 32-bit
   aligned.  Examples of the service data are the following:
      LFB configuration, status and events as carried in Primitive
      transfer messages
      FE capability and topology data (carried in Primitive transfer
      messages)
      Control protocol packets (also carried in Primitive transfer
      messages)
      TML configuration and association set up messages


   The variable length parameters in the payload are defined in a
   Tag-Length-Value (TLV) format as shown below:




     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Parameter Tag        |       Parameter Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \                                                               \
     /                       Parameter Value                         /
     \                                                               \




Audu, et al.             Expires April 21, 2005                [Page 16]
Internet-Draft                ForCES-IPTML                  October 2004



     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   Mandatory parameters MUST be placed before optional parameters in a
   message.
   Parameter Tag: 16 bits The Tag field is a 16-bit unique identifier of
      the type of the parameter.  It takes a value of 0 to 65534.
      Appendix-1 lists all used values of the Tag and related messages.
      Values other than those defined in specific parameter description
      are reserved for use by the IETF.
   Parameter Length: 16 bits The Parameter Length field contains the
      size of the parameter in bytes, including the Parameter Tag,
      Parameter Length, and Parameter Value fields.  The Parameter
      Length does not include any padding bytes.
   Parameter Value: variable-length The Parameter Value field contains
      the actual information to be transferred in the parameter.
      The total length of a parameter (including Tag, Parameter Length
      and Value fields) MUST be a multiple of 4 bytes.  If the length of
      the parameter is not a multiple of 4 bytes, the sender pads the
      parameter at the end (i.e., after the Parameter Value field) with
      all zero bytes.  The length of the padding is NOT included in the
      parameter length field.  A sender MUST NEVER pad with more than 3
      bytes.  The receiver MUST ignore the padding bytes.


5.3  ForCES-TML Messages


   This section defines the messages and their parameter contents.


5.3.1  Association and Connection


   These messages originate from the FE and CE entities in the ULP
   (Upper Layer Protocol).  They are exposed to the TML to allow the TML
   to allocate the necessary resources needed to form the association
   between peer ULP entities.


5.3.1.1  Join Request


   This allows a CE or an FE to join a CE-set.  The TML uses the
   information passed in to allocate management resources necessary for
   the CE-FE unicast-association.  The message contains the requester's
   identity (element tag, or address) that was configured during
   pre-association.  At a given point, CEs from one CE set can
   communicate with an FE.  The FE has to know which CE's requests it
   can accept.  This information is configured during the
   pre-association phase, during which a list of CEs allowed to control
   the FE is configured in the FE.  The FE uses this CE-list to send the
   join request.  It first tries one of the CE's in the list and if not




Audu, et al.             Expires April 21, 2005                [Page 17]
Internet-Draft                ForCES-IPTML                  October 2004



   successful, it tries the next CE in the list.  If all of the CEs in
   the list are tried without success, the FE should start over again
   until Retry timer expires.


   The format of the JOIN Message payload is as follows:


   Join Request



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x10)          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Source element            |     Destination element       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x20)          |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      o                            Address                            o
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                Figure 4


   The Join-Request message has the following parameters:
   Source Element: This is the element-tag of the source of the Join
      request.
   Destination Element: This is the element-tag of the target of the
      request.
   Address: The Interconnect dependent unique address of the FE.  The
      tag value determines the type of addressing used.


   After receiving a join request message, the TML performs the
   following operations.
      If the source of the Join request is a CE, the TML will match the
      target CE-Set in the request with those in its data base.  If
      found, the TML sends the request to the target CE of the Join
      request.  If not found, the TML allocates resources for the target
      CE-Set and sets the requesting CE ID as the controlling CE for
      this SET.  [ Note: This is probably better done by having a
      Create-CE-Set message.  However, his part should be removed
      because CE-to-CE communication is beyond scope of ForCEs]
      If the source of the request is an FE, the FE's TML sends the Join
      Request to the target CE's TML.  The target CE's TML will assign
      an association ID and forward the request (including the
      association ID) to the target CE if possible.  This association ID




Audu, et al.             Expires April 21, 2005                [Page 18]
Internet-Draft                ForCES-IPTML                  October 2004



      will be used to refer to future interaction between this CE-FE
      pair.
      If the request can't be delivered to the target TML, the source
      TML rejects the request with a proper reason code.  Also, if the
      request can't be delivered to the target CE, the target TML will
      send a reject with the appropriate reason code.  (See Leave
      Response)


5.3.1.2  Join Response


   On receiving a Join Response message from CE, the TML performs the
   following:
      Matches the association-ID component of the message against those
      in its database.  If found, the TML will forward the response to
      the target FE's TML.  If not found, the TML rejects it with
      [system error failure or Leave Response, with appropriate reason
      code].
      The TML at the target FE will forward the response to the FE,
      after noting the association ID in the message for future use.  It
      the TML can't deliver the message to the FE, the TML rejects the
      message with Leave Response with appropriate reason code.
      The TML at the target FE will forward the response to the FE,
      after noting the association ID in the message for future use.  It
      the TML can't deliver the message to the FE, the TML rejects the
      message with Leave Response with appropriate reason code.


   The format for the JOIN RESPONSE message payload is as follows:



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x50)          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Source Element ID          |       Destination Element ID  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Association ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Heartbeat Interval                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Association Expiry Timer                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     FE Behavior               | Behave Expiry Timer(opt)| Prio|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Audu, et al.             Expires April 21, 2005                [Page 19]
Internet-Draft                ForCES-IPTML                  October 2004



   Association-ID: This uniquely identifies the stream or virtual
      connection (wire) between the FE and CE.  Further communication
      between this FE-CE peer uses the stream.
   FE Behavior: This defines the FE behavior when all the CEs are down.
      A value of 1 indicates the FE should continue forwarding packets;
      a value of 0 indicates the FE should stop forwarding packets when
      the CEs are down.
   Heartbeat Interval: This gives the time interval for the heartbeat
      messages sent from the CE to the FE in milliseconds.
   Association Expiry Timer: This gives the timer value in milliseconds
      after which if the FE does not receive any heartbeat messages from
      the CE it should consider the association with the CE to have
      expired (CE DOWN).
   Behave Expiry Timer: This is an optional timer value, which applies
      in case the FE behavior is to continue forwarding packets when CEs
      are down.  This value indicates the time in seconds for which the
      FE should continue forwarding packets without associations with
      any CEs.  Value range from 0x0 (don't forward) to 0xffff (forward
      forever).
   Priority: This is the priority being requested for the association
      that may result from a successful join.


   Note that each FE can set up multiple unicast associations by making
   multiple Join requests, each with a different priority value.  This
   allows an FE to set up an association for control information and
   another one for user data exchange between the CE and the FE.  For
   this version of ForCES-PL/ForCEs-TML, the maximum limit is two (2)
   associations per FE.


5.3.1.3  Leave Request


   The FE can leave by sending Leave request to CE.  The CE's upon
   receiving such request releases the associated resources assigned for
   the FE.


   The FE's TML, on getting this request, will forward it to the target
   CE's TML based on the underlining association.  On getting the
   request, the target TML will forward it to the target CE for
   processing.


   The format for the LEAVE Message parameters is same as follows:



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0xa)           |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Audu, et al.             Expires April 21, 2005                [Page 20]
Internet-Draft                ForCES-IPTML                  October 2004



      |                              Reason                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x4)           |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      o                         INFO String*                          o
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




   The reason parameter indicates the reason the FE (or CE) is leaving
   the NE.  Valid values are as follows:


   The optional INFO String parameter can be any meaningful 8-bit
   character string (up to 255 characters).  This may be used for
   debugging purposes.


5.3.1.4  Leave Response


   When an FE has made a request to leave the CE, the CE generates an
   acknowledgment to the FE in the form of a Leave Response message.  A
   CE could have generated the Leave Request.  In this case, the
   (active) CE in the CE-set will generate the response sent to the
   leaving CE.


   (NOTE: Currently, CE-CE communication is out of scope and the mode if
   CE-CE communication is entirely proprietary)


   If a CE needs to reject a join request from a FE for some reason, it
   sends a Leave Response Message to the FE as well (Refer to Section
   5.1.2).


   In any case, this Leave Response will arrive at the sender's TML,
   which then forwards the response to the target.  The TML will then
   remove the association ID resources for that connection from its
   database.


   The format of the Leave Response message is the same as in the Leave
   Request message (See 5.1.3)


5.3.1.5  Join Multicast Address Request


   This used by the FE or CE to join a multicast address group.
   Messages sent from a group member will be sent to all other members
   in the group.


   The format of the JOIN MCAST-ADDR Message payload is as follows:






Audu, et al.             Expires April 21, 2005                [Page 21]
Internet-Draft                ForCES-IPTML                  October 2004



   Join MCast Address Request




       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x20)          |             Length (8)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       >                            Address                            <
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x10)          |             Length (8)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Mcast_Address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  reserved                               | prio|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                Figure 5


   Address: The Interconnect dependent unique address of the FE.  The
      tag value determines the type of addressing used.
   Mcast_Address: This is the multicast group address being joined.
   Link Priority: This is the  value of the priority for the link that
      may result from the join request.  The value set here will be
      reflected in the Prio header bits for data exchanges between
      source and sink using the requested multicast address.


   On getting this message, the TML performs the following operations:
      The TML at the FE will forward the request to the target CE's TML.
      The TML at the CE will try to match the address group in the
      message with the list in its database.  If successful, the
      sender's unique address contained in the message is added to the
      address group.  A Join Multicast Address Response message is then
      sent to the requestor.  If the address group doesn't exist
      however, the TML will reply with a Leave Multicast Address
      Response with the appropriate reason code.


5.3.1.6  Join Multicast Address Respone


   This is the response sent to a requester after a successful multicast
   address Join process.  The format of the body of this message is the
   same as in the request (see 5.1.5).


   Note this message will typically be sent by the TML (Transport




Audu, et al.             Expires April 21, 2005                [Page 22]
Internet-Draft                ForCES-IPTML                  October 2004



   layer).


   If the join request was not successful for some reason, a Leave
   Multicast Address response (see 5.1.8) will be sent back to the
   requester.


   On getting this message, the TML performs the following operations:
      CE TML.  This message is generated by the CE's TML.  It sends the
      response message to the target FE's TML, which then forwards it to
      the FE.
      After a successful multicast address join, any message sent from
      the CE to the group address will be replicated to each FE on the
      group address list.


5.3.1.7  Leave Multicast Address Request


   This message is sent by a CE or an FE endpoint to signal its
   intention to stop receiving multicast messages sent to a particular
   group address.


   The format of the LEAVE MCAST_ADDR Message payload is as follows:


   Leave Multicast Address Request




      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x21)          |             Length (8)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Mcast_Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x0a)          |             Length (8)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Reason                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                                Figure 6


   Mcast-Adress: This is the multicast address being vacated.
   Reason: Reason for leaving the group


   On getting this message, the TML performs the following operations:





Audu, et al.             Expires April 21, 2005                [Page 23]
Internet-Draft                ForCES-IPTML                  October 2004



      TML at the FE simply forwards message to the target CE's TML.
      On getting the request, TML at the CE will remove the requestor's
      unigue address from the address group list (if the address group
      is present).  It then sends a Leave Multicast Address Response to
      the requestor, with the appropriate reason code.


5.3.1.8  Leave Multicast Address Response


   This is sent to the requesting FE or CE to acknowledge a successful
   discontinuation of the requestor's membership in a multicast address
   group.  It can also be sent in the event of an unsuccessful join-
   multicast-address request.  Thereafter, messages sent to that
   multicast address will not be delivered to that endpoint.


   The LEAVE MCAST-ADDR response message contains the following
   parameters:


   The format for the LEAVE MCAST-ADDR Message parameters is same as
   follows:


   Leave Multicast Address Response




       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x20)          |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Mcast_Address                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0xa)           |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              Reason                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x4)           |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       0                         INFO String*                          0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                Figure 7


   Reason: The reason for leaving the multicast group.
   Info-String: The optional INFO String parameter can be any meaningful
      8-bit character string (up to 255 characters).  This may be used
      for debugging purposes.





Audu, et al.             Expires April 21, 2005                [Page 24]
Internet-Draft                ForCES-IPTML                  October 2004



      Valid reasons for leaving an address group are as follows:


   Note: This message will typically be sent by the TML layer if
   present.


   The TML at the FE, on getting this response, forwards the message to
   its FE.


5.3.2  Primitive Transfer Messages


   These messages are used by the ULP to send application messages
   opaquely via the TML.  The sender must have successfully created an
   association with a receiving peer (via the JOIN, or Join Multicast
   process).  For example, CEs and FEs will use these messages to
   exchange capability information, configuration information, etc.


5.3.2.1  Reliable Data Transfer Request


   This message is used by the TML layer to send application data to the
   peer TML in a reliable mode.


   The protocol data of this message is as follows:




       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x30)          |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       0                          Protocol Data                        0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The protocol data will contain packets carrying requests or responses
   between peer ULP protocols.


5.3.2.2  Reliable Data Transfer Resposne


   TBD


5.3.2.3  Unreliable Data Transfer Request


   This is used by the TML layer to send application data to the peer
   TML via the unreliable (i.e.  UDP-like) mode.


   The protocol data of this message is as follows:





Audu, et al.             Expires April 21, 2005                [Page 25]
Internet-Draft                ForCES-IPTML                  October 2004



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x30)          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      0                          Protocol Data                        o
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




5.3.2.4  Unreliable Data Transfer Respone


   TBD.


5.3.3  Security Association


   CEs and FEs have to be authenticated by the CE's TML before
   communication can occur between peer endpoints.  The SA messages are
   used to provide authentication for the endpoints.


   [Details filled in later]


5.3.4  Management and Maintenance Messages


   These set of messages are used to manage the TML layer itself.


5.3.4.1  Error Reporting


   The Error TLV is used to notify the ULPs in CE or FE of an error
   associated with an incoming synchronous Request message.  For
   example, the message might be unexpected, given the current state, or
   a parameter value might be invalid.  This Error TLV can be sent as a
   result of a request (synchronous), or it could be triggered
   asynchronously as a result of asynchronous events occuring in the
   system.


   The format of the Error TLV is as follows:




       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0xc)           |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           Error Code                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Audu, et al.             Expires April 21, 2005                [Page 26]
Internet-Draft                ForCES-IPTML                  October 2004



   The Error Code parameter indicates the reason for the error.


5.3.4.2  HeartBeat Request


   CE-TML periodically polls each FE-TML to ensure that it is
   operational.  Any errors will be reported via the event asynchronous
   event handling.


   A CE-TML starts generating these messages after the  FE-TML has
   successfully authenticated and joined the CE-TML.  The timers for
   these messages are configurable during pre-configuration and can be
   different for the active and standby CE-TMLs.  The heartbeat interval
   for a standby CE-TML can be much larger than that of the active
   CE-TML.


   An optional Heartbeat Data parameter may be sent in the heart beat
   message.  Its contents are defined by the sending node and are
   simply echoed back by the receiving FE via the HB-ACK message (see
   below).  Examples of values encoded in the Heartbeat Data field by
   FE-TMLs could include a Heartbeat Sequence Number or Timestamp.  The
   receiver of a Heartbeat message does not process this field as it is
   only of significance to the sender.  The receiver MUST respond with a
   Heartbeat Acknowledgement message.


   The format for the Heartbeat Message is as follows:




      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Tag (0x9)           |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      O                         Heartbeat  Data                       0
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





5.3.4.3  HeartBeat Acknowledge


   The receiving FE simply echo's the original heartbeat message back to
   the sender.


5.3.5  Event Notification


   Various events in the data path can be monitored for by the FE and
   reported to the CE.  The CE must first inform the FE which of these




Audu, et al.             Expires April 21, 2005                [Page 27]
Internet-Draft                ForCES-IPTML                  October 2004



   events it is interested in through a registration process.


5.3.5.1  Asunchronous Events Notification


   This is used to report asynchronous events occurring in the FE.
   These could be overall FE errors, Port/Link errors or Logical
   Component specific events.  The message contains the following:


   The format of the ASYNC-NTFY message is as follows:



       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x1e)          |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Event Type              |          Event ID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Logical Component Handle                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Tag (0x7)           |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       o                        Diagnostic Info                        o
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Valid values of the Event ID are as follows:


5.3.6  Vendor Specific Extensions


   This allows vendor specific TML extension messages to be transported
   opaquely over the ForCES-TML protocol.  This way,  currently unknown
   TML functionality (outside of those already specified) can be
   expressed.


5.3.6.1  Vendor Specific Data Request


   TMLs may use this message to pass any information that is not to be
   consumed by TML protocol proper to each other.  This message is used
   by the extension module of a TML to send extension specific data to
   peer TML's extension module.


   Payload structure for Vendor Specific (VS) Request is as shown below.



      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Audu, et al.             Expires April 21, 2005                [Page 28]
Internet-Draft                ForCES-IPTML                  October 2004



      |           Tag (0x4e)          |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      o                   Data to be transported                      o
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




5.3.6.2  Vendor Specific Data Response


   This is used by the extension module in the TML that receives an
   Inter-TML-extension-module communication message to acknowledge the
   reception to the original sender.


   The format of this message is same as for VS-DATA Request.


5.3.7  ForCES-TML Interfaces


   Force-TML protocol interfaces with an upper-layer protocol (in this
   case the Forces-PL), and a lower protocol (in this case, the
   IP/TCP/UDP/SCTP protocols).


   The upper layer protocol shall request services passing primitives to
   the TML layer and shall receive notifications from the TML layer for
   various events.


   The primitives described in this section should be used only as a
   guideline in implementing TML APIs.


5.3.7.1  ULP-to-TML Interface


   The following describe the ULP/TML interface functions.  These are
   the basic functions the TML must perform to support inter-ULP
   communication.


   Initialize::


   Format: Initialize()


   Return -> Local instance name of the TML.  This primitive allows TML
   to initialize its internal structures and allocate resources to
   support the ULP peer communication.


   Authenticate Endpoints::


   Format: Authenticate(parameters yet to be determined)


   Return -> Pass or Fail This is used to authenticate the endpoints
   prior to them engaging in communication.  In this exercise, the CE




Audu, et al.             Expires April 21, 2005                [Page 29]
Internet-Draft                ForCES-IPTML                  October 2004



   and its TML are the trusted entities.  All FEs and FE-TMLs have to be
   authenticated using this primitive.  Details are TBD


   Join (or Associate)::


   Format: Join(source address, destination address)


   Return -> Pass or Fail This is used to create a unicast association
   between the source address and the destination address that resides
   on the peer TML endpoint.


   Join Multicast (or Associate Multicast)::


   Format: Join-Multicast(source address, multicast-group-Address)


   Return -> Pass or Fail This is used to create (if not already
   created) and register source address with multicast-group-address
   handling for the purpose of message distribution.An association will
   be established between the CE TML and the appropriate FE TML for the
   purpose of message distribution.


   Leave::


   Format: Leave(source address)


   Return -> Pass or Fail  This is used by an entity in the ULP to leave
   a unicast association the entity currently belongs in.


   Leave Multicast::


   Format: LeaveMulticast(source address, multicast-group-address)


   Return -> Pass or Fail This is used by an entity in the ULP to leave
   the specified multicast group association the entity currently
   belongs in.


   Shutdown::


   Format: Shutdown(association/stream ID)


   Return -> Pass or Fail Gracefully close an association or stream.
   Any locally queued data will be delivered to the peer.  A success
   code will be returned on successful termination of the association.
   If a failure results, an error code will be returned.


   Abort::


   Format: Abort(association or stream-ID, reason-code)




Audu, et al.             Expires April 21, 2005                [Page 30]
Internet-Draft                ForCES-IPTML                  October 2004



   Return -> Result Code (Pass or Fail) Ungracefully close down an
   association or stream.  Any locally queued user data will discarded,
   and an abort message with the reason code sent to the peer.If
   successful, a success code will be return, else, an error code will
   be returned.


   Send Reliable ::


   Format: SendReliable(association-id, buffer-address, byte-count,
   destination-address)


   Return = Result Code This is used to send user data between peer ULPs
   via TML using a reliable mechanism.  In this document, the
   destination-address will be the element tag of the target.  (i.e.
   CE-SET:CE-Identifier, or FE-SET:FE-Identifier).


   Send Unreliable::


   Format: SendUnreliable(buffer-address, byte-count,
   destination-address)


   Return -> Result Code (Pas or Fail) This is used to send user data
   between peer ULPs via TML using an unreliable mechanism.


   Receive::


   Format: Receive(association-id, buffer-address, buffer-size)


   Return -> byte count delivered This is used by ULP to read user data
   in TML in-queue into specified buffer in ULP.  Size of message read
   is returned.


   Status::


   Format: Status(association-id)


   Return -> Status data of the association or stream  This primitive
   will return a data block containing status information of the
   specified stream or association.  .association connection state,
   .association error counts, .destination address


5.3.7.2  TML-to-ULP Interface


   The following describe the TML/ULP interface functions.  These are
   the basic functions the TML must perform to asynchronously provide
   data to the ULP.  [TBD]






Audu, et al.             Expires April 21, 2005                [Page 31]
Internet-Draft                ForCES-IPTML                  October 2004



5.3.8  Scenarios


   TBD


5.3.9  Security Considerations


   [Yet to be determined]


5.3.10  IANA Considerations


   [Yet to be determined]









































Audu, et al.             Expires April 21, 2005                [Page 32]
Internet-Draft                ForCES-IPTML                  October 2004



6.  References


6.1  Normative References


   [I-D.ietf-forces-model]
              Yang, L., "ForCES Forwarding Element Model",
              draft-ietf-forces-model-03 (work in progress), July 2004.


   [I-D.ietf-forces-protocol]
              Doria, A., "ForCES Protocol Specification",
              draft-ietf-forces-protocol-00 (work in progress),
              September 2004.


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


   [RFC3654]  Khosravi, H. and T. Anderson, "Requirements for Separation
              of IP Control and Forwarding", RFC 3654, November 2003.


   [RFC3746]  Yang, L., Dantu, R., Anderson, T. and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004.


6.2  Non-Normative References



Authors' Addresses


   Alex Audu
   Alcatel
   3400 West Plano Parkway
   Plano Texas
   USA


   Phone:
   EMail: alex.audu@alcatel.com



   Jamal Hadi Salim
   Zynx Networks
   Ottawa, Ontario
   Canada


   Phone:
   EMail: hadi@zynx.com







Audu, et al.             Expires April 21, 2005                [Page 33]
Internet-Draft                ForCES-IPTML                  October 2004



   Avri Doria
   ETRI



   Phone:
   EMail: avri@acm.org














































Audu, et al.             Expires April 21, 2005                [Page 34]
Internet-Draft                ForCES-IPTML                  October 2004



Appendix A.  Acknowledgement


   TBD

















































Audu, et al.             Expires April 21, 2005                [Page 35]
Internet-Draft                ForCES-IPTML                  October 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Audu, et al.             Expires April 21, 2005                [Page 36]