ForCES Working Group                                      W. M. Wang
     Internet-Draft                              Zhejiang Gongshang Univ.
     Expires: October, 2006 August, 2007                                  J. Hadi Salim
                                                            Znyx Networks
                                                                Alex Audu
                                                         Garland SoftWorx
                                                           February, 2007

             ForCES Transport Mapping Layer (TML) Service Primitives

                        draft-ietf-forces-tmlsp-00.txt

                          draft-ietf-forces-tmlsp-01.txt

  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 (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 [RFC2119].

  Abstract

     This document proposes Service Primitives of specifies Transport Mapping Layer (TML) in a Service
     Primitives for Forwarding and Control Element Separation (ForCES) network
   element, to standardize (ForCES).
     Based on the operations of service primitives, TML services that are provided by
     TML to ForCES Protocol Layer (PL)
   to a variety of TMLs. are standardized. To define the
     primitives, TML properties represented as TML events, TML attributes,
     and TML capabilities are also specified in the document.

  Table of Contents

     1. Introduction....................................................2
     2. Definitions.....................................................3
     3. Overview........................................................3
        3.1. ForCES Protocol Framework..................................3
        3.2. TML Requirements...........................................4
     4. TML Modeling....................................................5 Representation..............................................5
        4.1. TML events.................................................6
        4.2. TML attributes.............................................9 attributes............................................11
        4.3. TML capabilities..........................................12 capabilities..........................................14
     5. TML Service Primitives.............................................13 Primitives.........................................15
        5.1. Design Principles.........................................13 Principles.........................................15
        5.2. Objectives................................................13 TML Open..................................................15
        5.3. TML Open..................................................13 close.................................................16
        5.4. TML close.................................................14 Configuration.........................................17
        5.5. TML Configuration.........................................15 Query.................................................18
        5.6. TML Query.................................................15 send..................................................20
        5.7. TML send..................................................16
      5.8. TML receive...............................................17 receive...............................................21
     6. Theory of Operation............................................17 Operation Notes................................................22
     7. References.....................................................17 Security Considerations........................................23
     8. Acknowledgements...............................................24
     9. References.....................................................24
     10. Author's Address...............................................17
   Appendix A. TML Attributes XML file...............................18 Address..............................................24

  1. Introduction

   The Forwarding and Control Element Separation (ForCES) is

     ForCES aims to define a proposed
   architecture set of specifications for network elements like routers, documents of which
   include RFC3654, RFC3746, and firewalls,
     gateways, etc based on the ForCES protocol[ForCES-PL] architecture of separation of Forwarding
     Elements (FEs) and the
   ForCES FE model[ForCES-Model] that are work in progress. Control Elements (CEs). RFC3654
   defines has presented the
     ForCES requirements, and RFC3746 defines has defined the ForCES framework,
   and framework.
     The ForCES FE model [ForCES-Model] is specifying the model to
     represent an FE. The ForCES protocol defines [ForCES-PL] is specifying the message exchange
     information exchanging protocol between
   the Forwarding Element (FE) CE and the Control Element (CE) in the
   ForCES NE (see RFC3654 for the terminology definitions). FE.

     The ForCES protocol infrastructure consists of two components: layers:

     1. The Protocol Layer (PL), which is responsible for generating
     ForCES protocol messages messages, and also processing protocol messages that come
     from peering protocol layers layer in the same ForCES NE.

Hadi Salim               Expires Oct., 2006                [Page    2]

     2. The Transport Mapping Layer (TML), which is responsible for
     transportation of ForCES protocol message transports messages over variant transport media
     media, like IP, Ethernet, ATM, etc.

     The IETF ForCES protocol mainly [ForCES-PL] document defines the PL. specifications
     for PL, while TMLs according to
   various of different transport media types are also to be individually
     defined by IETF. individual IETF documents. A ForCES PL implementation must
     be portable across all TMLs. It is feasible that the implementers of
     TML and PL may be from different organizations. As a result, there must be an interoperable method services
     TML provides to
   interconnect the PL and TML. A private method would make the PL and
   TML implementations also private. must be specified in a standardizing way.

     The purpose of this document is to present specify the method services that various
     TMLs must provide for an
   interoperable interconnection of the ForCES PL and a variety of TMLs.
   Although there might be other choices like using PL-TML messages, as
   a more efficient way for data transmission and processing, a method
   based on service primitives layer. The TML services are recommended for interconnection of PL
   and TML. In this document,
     represented by a set of TML Service Primitives are
   presented service primitives and related associated TML parameters are defined. Also presented in
   the
     properties (TML attributes, etc).

     Note that this document is the theory of operation of PL-TML based specifies TML services more at a semantic
     level, i.e., it does not try to specify details on how the
   service primitives defined
     TML services shall be implemented. Different Operating System
     platforms that PL and TML may rely on to be developed may have
     different programming methods, process techniques, data structures,
     etc for realizing the parameters. set of TML services. As a result, TML interface
     APIs constructed according to this document may vary in some way. In
     this condition, one PL portable to various TMLs actually means the PL
     must provide various interface drivers for different TMLs, while
     keeping the PL kernel the same for the TML operations.

  2. Definitions

     This document follows the terminology used by RFC3654, RFC3746, the
     ForCES protocol[ForCES-PL], and the ForCES protocol[ForCES-PL]. Some FE model [ForCES-Model].
     For convenience, some definitions are just copied here:

     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 [ForCES-PL].

     ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
     ForCES protocol architecture that uses the capabilities of existing
     transport protocols to specifically address 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.
     The ForCES TML specifications are detailed in separate ForCES
     documents, one for each TML.

  3. Overview

  3.1. ForCES Protocol Framework
     The ForCES protocol document has presented the protocol framework as
     in Figure 1. The framework shows the relationship between PL Protocol
     Layer (PL) and TML. Transport Mapping Layer (TML). According to this
     framework, TML lies under PL and provides transportation services for
     protocol messages to the PL.  CE PL communicates with FE PL via CE TML
     and FE TML. On

Hadi Salim               Expires Oct., 2006                [Page    3]
   transmit, the transmission, PL delivers its ForCES messages to the its
     TML. The TML further delivers the message messages to the destination peering
     TML(s). On receive,
   the TML delivers the ForCES messages it has received to the
     its PL.

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

         +-------------------+                  +-------------------+
         |    CE PL layer    |
               +-----------------------------------------------                  |              CE TML    FE PL layer    |
               +-----------------------------------------------
                                         ^
                                         |
                               ForCES    |
                               protocol  |
                               messages  |
                                         |
         +-------------------+                  +-------------------+
         |    CE TML layer   |
                                         v
               +-----------------------------------------------                  |    FE TML layer   |
               +-----------------------------------------------
         +-------------------+                  +-------------------+
                   ^                                      ^
                   |               FE PL layer        ForCES protocol messages      |
               +-----------------------------------------------
                   +--------------------------------------+

                      Figure 1 1. ForCES Protocol Framework

  3.2. TML Requirements

     The ForCES protocol [ForCES-PL] docuement has also presents presented TML requirements.
     We list the requirements as below. These requirements are expected to be
   delivered by TML using any kind of transport media, though the text
   does not define how such mechanisms are delivered. Each TML specification must
     describe how it contributes to achieving the requirements. If If, for
     any
   reason reason, a TML does not provide a service listed below by the
     requirements, a justification needs to be provided.

     The TML requirements are:

     1. Reliability
     As defined by RFC 3654, section 6 #6.

     2. Security
     TML provides security services to the ForCES PL. TML layer should
     support the following security services and describe how they are
     achieved.

            *  Endpoint authentication of FE and CE.

            *  Message Authentication

Hadi Salim               Expires Oct., 2006                [Page    4]

            *  Confidentiality service

     3. Congestion Control
     The congestion control scheme used needs to be defined. The
     congestion control mechanism defined by the TML should prevent the FE
     from being overloaded by the CE or the CE from being overwhelmed by
     traffic from the FE.  Additionally, the circumstances under which
     notification is sent to the PL to notify it of congestion must be
     defined.

     4.Uni/multi/broadcast addressing/delivery if any
     If there is any mapping between PL and TML level Uni/Multi/Broadcast
     addressing it needs to be defined.

     5. HA decisions
     It is expected that availability of transport links is the TML's
     responsibility.  However, on config basis, the PL layer may wish to
     participate in link failover schemes and therefore the TML must
     support this capability.

     6. Encapsulations used.
     Different types of TMLs will encapsulate the PL messages on
     different types of headers. The TML needs to specify the
     encapsulation used.

     7. Prioritization
     It is expected that the TML will be able to handle up to 8 priority
     levels needed by the PL layer and will provide preferential treatment.
     TML needs to define how this is achieved. The requirement for
     supporting up to 8 priority levels does not mean that the underlying
     TML MUST be capable of handling up to 8 priority levels.  In such an
     event the priority levels should be divided between the available TML
     priority levels.  For example, if the TML only supports 2 priority
     levels, the 0-3 could go in one TML priority level, while 4-7 could
     go in the other.

     8. Protection against DoS attacks
     As described in the Requirements RFC 3654, section 6

  4.  TML Modeling

   To make PL capable of interconnection with variant TMLs in a
   standardized way, the first work to do Representation

     The document is to model the variant TMLs
   in a uniform way from the perspective of define a uniform PL.

   Identical to modeling an LFB in an FE, from the perspective set of PL,
   TML properties can be abstracted by the following entities:

   TML Events:

Hadi Salim               Expires Oct., 2006                [Page    5]
   The general services for TML events that
     various TMLs and their implementations must fundamentally provide for
     ForCES PL requires to know when layer. For this sake, a TML representation is necessary
     that describes general properties of various TMLs. The following
     entities are used to represent various TML properties.

     TML Events:
     When the events happen in
   the TML. TML, PL may be interested to be notified.

     TML attributes:
   The
     Represent the TML attributes parameters that are required to should be configured by PL
   according to when PL requirements. The attributes can also be queried by
   PL.
     asks TML to provide services.

     TML capabilities:
   The
     TML capabilities abilities or capacities that PL are is interested to know.

     Note that, not all TML properties should be made perceivable and
     controllable by PL
   from PL point of view. PL. PL only cares those TML properties that are
   common to all TMLs and that PL should
     interact with via service
   primitives so that in order for TML can work according to PL's requirements.

   Via TML Service Primitives, PL should be able properly provide services to access above
   properties of variant TMLs.

4.1.TML the PL.

  4.1. TML events

   There might be several

     TML events, but only some of them events are PL must
   sense via PL-TML interface.

   A callback mechanism triggered by some TML status changes when TML is defined for
     running. PL layer may be interested to sense the be notified when some TML
     events by
   PL-TML service primitives. occur. TML is responsible to asynchronously notify PL first provides every of these
     events.

     How a TML event with is asynchronously notified to PL highly depends upon
     operating system environments PL and/or TML implementations may be
     based. As an example, some environments may adopt a callback function
     mechanism for notification of events between program processes. In
     this case and for the event processing in the PL. PL/TML usage, PL then tells
   the may first construct a callback handle
     function to process every event, and then tell TML by service primitives. The the callback handle
   is usually stored in TML as a parameter.
     function handle. Whenever the relavent an interested event happens in TML, the TML triggers the handle to
     will notify PL of the event.
   PL executes event by invoking the callback function, handle and asynchronously begins to
   process let
     PL execute the callback function. In this way, the event.

   After a TML asynchronously
     passes the event happened and PL is notified and a procedure notification to
   process the event is executed, PL may be further interested PL.

     However, this document does not try to define specific means for
     PL/TML notification. Any appropriate means can be adopted under
     condition that it shall meet the service requirements.

     A TML event may appear as a sustained event, i.e., the event will
     last until the condition triggered the event is changed and the event
     is then released. For instance, when an error happens in
   knowing if TML, it will
     last until the error is finally by any means removed. In the
     sustained event status case, PL may be interested in knowing not only when
     the TML still exists or not. event takes place, but also when the event is released. To meet
     this requirement, need, an 'eventState' event status parameter is used in callback
   functions to indicate if the reported is should be defined and associated
     with a sustained event report. The parameter will mark the associated
     event happened with either 'occurring' or 'is released' to indicate the
   event released. Whereas, two
     different status of a sustained event. Nevertheless, not all events
     are sustained events, so that not all event reports need this kind of
     parameters.

     A TML event shall be distinguished as being subscription-free or
     subscription-requested. A subscription-free TML event will inevitably
     be notified to notify PL when it occurs. A subscription-requested TML event
     is only notified to PL when it has been subscribed for by the PL. A
     way for PL to subscribe for a subscription-requested TML event will
     be provided by defining an event handle TML attribute as in 1) of their
   release state.
     Section 4.2. The following TML attribute can also provide more events
     parameters configuration. See Section 4.2 for more details on the
     attribute definition.

     An TML event is assigned a TML event id, so that PL can identify the
     event uniquely.

     Followed are descriptions of TML events that must be made to be notified by PL. If available for
     all TML specifications. If, for any reason a reason, an individual TML
     specification does not provide the service, events, a justification needs to
     be provided in the TML specification.

     1) TML failure error event

     This event happens when there is reports a TML failure. It is up to
   individual error during TML specifications and even individual implementations running to

Hadi Salim               Expires Oct., 2006                [Page    6]
   specify PL. When the detailed
     event triggering conditions, but usually, is invoked, something might be wrong in the TML. Failures like
     TML link failure should include in TML are also taken as TML errors, which can be
     understood as fatal errors for some cases.

     When the event occurs and an event report is notified to PL, an
     error code is associated with the event report so as to pass more
     information about the error to PL layer. The code may expose PL the
     reason of the error, the type of the error, as such.

     TML error event is a subscription-free event. When the event occurs,
     it will always invoke a report to PL.

     TML error event is a sustained event. The error status will last
     until the error is removed by any means.

     As a result, when the event is notified to PL, the following
     information shall be associated with the event report:

       o TML error code and associated data

       o event status
               1    The event is occurring
               0    The event is released

     Note that it is not restricted that more information may also be
     associated with the event report, depending upon each TML
     specification or implementation.

     This document defines the following cases:
   . TML errors and associated data.
     These errors are usually common to all types of TMLs.

      TML error code    TML error                  Associated Data

           1        all local TML link failure      none
           2        some local TML link failure
   .  peer TML CE/FE ID(s) the
                                                 link is connected
           3          peer TML unavailable
   .       peer TML CE/FE ID(s)
           4          peer TML abnormally left

   The different cases that cause the failure will be stated by   peer TML CE/FE ID(s)
     Each TML specification may define its specific errors. There is also
     a
   failure code in the event callback function.

   Callback handle room for each TML failure implementation to define specific errors.

     TML error event is then defined as:

     status =              -- SUCCESS or errorIndication
              callbackTMLFailureEvent(
                        IN   eventState
                        IN   failCode
                                      )
   Where,
        eventState assigned with a TML event id = EventHAPPENED or EventRELEASED
        failCode indicates the failure case 1.

     2) Message arrival arrive event

     TML can shall be able to make it as an event occurrence when it has
     received a PL ForCES protocol message coming from peering TML arrives at the peer TML and the TML has made it
     ready for
   PL to receive the message. deliver to local PL. In this way, an asynchronous message
     receive mode can be realized in PL. In addition to this asynchronous
     mode, PL can also use a specific TML receive service primitive
   (defined below) as
     defined in Section 5.8 for PL synchronous reception receiving of ForCES
     messages.

     This event is a subscription-requested event, i.e, unless PL has
     requested TML to do so, TML will not use an asynchronous event
     notification way to deliver arrived messages to PL. In this case, PL
     can still use a TML receive primitive to receive ForCES messages.

   Callback handle for message arrival

     When the event is defined as:

     status =              -- SUCCESS or errorIndication
              callbackTMLMsgArrivalEvent(
                           IN   msglen
                           IN   msgPDU
                                         )
   Where, msglen indicates notified to PL, the following information shall be
     associated:

        o the arrived ForCES message length, and msgPDU is length

        o the whole arrived ForCES message body in its Protocol Data Unit format. There (PDU)

     It is no
   need for message arrival event to notify a release state.

   3) Control message congestion event

   ForCES control messages are defined as all ForCES protocol messages
   except ForCES redirect messages. ForCES redirect messages are
   identified by the ForCES message types being marked as
   'PacketRedirect'.

   This not restricted that other information might also be associated
     with this event happens when the report, depending upon requirements of individual TML comes to a congestion state for
     specifications or implementations.

     Note that the
   control message transmission. It arrive event is up to individual TML

Hadi Salim               Expires Oct., 2006                [Page    7]
   specifications not a sustained event, and even individual implementations
     there is no need to specify distinguish its status as occurring or released.
     When the
   detailed event triggering conditions.

   This event can be used by PL layer message is reported to monitor PL, the control message
   transmission. In FEs, this event may also be used to help monitoring
   possible DoS attacks from redirected packets.

   Callback handle for is automatically
     released.

     TML control message congestion arrive event is defined
   as:

     status =              -- SUCCESS or errorIndication
              callbackTMLCtrMsgCongestEvent(
                            IN   eventState
                                            )
   Where,
        eventState assigned with TML event id = EventHAPPENED or EventRELEASED

   4)Redirect message 2.

     3) TML congestion event

   This event happens when the alert

     Although it is expected that TML comes to provide a congestion state for the
   PL redirect ForCES message transmission. It
     transportation free of congestion, as a general problem for current
     Internet society, congestion problem is up still quite hard to individual TML
   specifications and even individual implementations to specify the
   detailed event triggering conditions.

   This event can be used by
     completely avoided if mechanisms are purely limited in TML resources
     and without help from PL layer to monitor the redirect message
   transmission. resources. In FEs, this may also be used to many cases, with the help monitoring
   possible DoS attacks from redirect packets.

   Callback handle for
     the resources in PL layer, congestion problem may be much better
     suppressed. For example, in cases where the OS a TML redirect message adopts is
     capable of detecting an ECN (Early/explicit congestion event notification)
     where the underlying IP protocol is defined
   as:

     status =              -- SUCCESS or errorIndication
              callbackTMLRedMsgCongestEvent(
                              IN   eventState
                                            )
   Where,
        eventState = EventHAPPENED or EventRELEASED

   5)DoS attack alert event

   This event happens when capable of passing information to
     the application, then the TML comes could pass such information to a state that it feels there
   are abnormal amount of the PL.
     The PL redirect messages and there has made it
   quite hard could use this information for example to transport adjust its sending
     rates or increase or reduce the priority of certain PL control messages. Whereas, it is up to
   individual TML specifications and messages, etc.
     More over, even individual implementations to
   specify in the detailed and precise triggering conditions case PL could help little for the event.

   This event TML congestion,
     it is used by still very helpful for PL to monitor know the security TML congestion state for if
     it does happen. As a result, in the TML
   message transmission. In FEs, when this event happens, usually FE requirement in Section 3.2,
     it is required that TML must be defined with a method to notify PL
   should trigger of
     congestion state.

     This document specifies that a DoS attack TML congestion alert event must be
     supplied with various TMLs and their implementations if the TMLs and
     implementations are not free from congestion problems due to inform CE any
     reasons. TML notifies PL of the congestion state by this TML congestion
     alert event. CE
   may take further effects trying to prevent the attack. Note that, the

Hadi Salim               Expires Oct., 2006                [Page    8]
   event It is an alert, when it happens, usually it does not mean the CE-
   FE communication is totally lost.

   Callback handle for TML DoS attack alert event is defined as:

     status =              -- SUCCESS or errorIndication
              callbackTMLDoSAttackAlertEvent(
                              IN   eventState
                                             )
   Where,
        eventState = EventHAPPENED or EventRELEASED

4.2.TML attributes

   1) Event handles

   Event handles are handles for because we expect that TML notifies
     PL to access events. An of the event callback
   function handle when TML is used as in danger of, rather than in the purpose. Defining state of,
     congestion. An alert event is more helpful, because TML is the handles as only
     path that an
   attribute FE is connected to CE, and a complete congestion state
     in TML may lead to CE lost control of the TML, then, FE, which is fatal for PL to set the handle to
     FE.

     A TML congestion alert event is defined as a subscription-requested
     event. It means PL will subscribe for it if PL requires the
     congestion alert. During some usage cases or during some period of
     usage, PL may not be interested to subscribe be notified of such event. For
     instance, in many cases, congestion problem at CE side are not so
     serious as that at FE side where FE side often risk DoS attacks from
     redirect data. In this case, CE side congestion alert event may be
     turned off so as to the save CPU resources, while FE side congestion
     alert is always open.

     A TML for the congestion alert event notification, is a sustained event. When congestion
     alerts, it will last until its state is changed back to delete
   the handle from free of
     danger for congestion. TML should notify PL twice for the whole
     congestion report. When there is a congestion alert, TML sends one
     notification to PL, when it is released, TML sends another
     notification to unsubscribe the PL.

     TML congestion alert event from the TML.

   We define is assigned with TML event id = 3.

     When the event handle is notified to PL, the following information will be
     associated with its report:

       o TML attribute as below:

   <dataTypeDef>
     <name>Eventhandle</name>
     <synopsis>Event callback handle</synopsis>
     <struct>
       <element elementID="1">
         <name>eventType</name>
         <synopsis>event congestion alert type represented by an ID </synopsis>
         <typeRef>uint16</typeRef>
         <specialValues>
           <specialValue Value="1">
             <name>TMLFailureEvent</name>
             <synopsis>TML failure event</synopsis>
           </specialValue>
           <specialValue Value="2">
             <name>TMLMsgArrivalEvent</name>
             <synopsis>TML ForCES message arrival event</synopsis>
           </specialValue>
           <specialValue Value="3">
             <name>TMLCtrMsgCongestEvent</name>
             <synopsis>
             TML ForCES congtrol message transmit congestion event
             </synopsis>
           </specialValue>
           <specialValue Value="4">
             <name>TMLRedMsgCongestEvent</name>
             <synopsis>

Hadi Salim               Expires Oct., 2006                [Page    9]
             TML ForCES redirect
               1    congestion alert from control message transmit transmission
               2    congestion event
             </synopsis>
           </specialValue>
           <specialValue Value="5">
             <name>TMLDoSAttackAlertEvent</name>
             <synopsis>TML alert from redriect message transmission
               3    alert from redirect DoS attack alert event</synopsis>
           </specialValue>
         </specialValues>
       </element>
       <element elementID="2">
         <name>handle</name>
         <synopsis>callback function handle of the event</synopsis>
         <typeRef>uint64</typeRef>
       </element>
     </struct>
   </dataTypeDef>

   <attribute access="read-write" elementID="1">
     <name>EventHandles</name>
     <synopsis>event handle table in the TML</synopsis>
     <array>
        <typeRef>EventHandle</typeRef>
     </array>
   </attribute>

   2)multicast lists

   This attribute
       o event status
               1    The event is used for TML to multicast ForCES messages. happening
               0    The
   multicast list should event is released
     Note that it is not restricted that other information may also be configured by PL, but
     associated with the congestion alert report, depending upon
     individual TML specifications should define how such multicast list maps to TML
   transport level multicast mechanisms.

   A PL level multicast list includes a group ID for the multicast and
   a number of members of the multicast. The members are represented by
   PL level protocol src/destIDs (include FE ID and CE ID).

   Note that, there might be more than one multicast group for
   multicast applications. The multiple multicast lists form a multicast
   list table in TML.

   The attribute for the multicast lists is defined as below:
                     }
   <dataTypeDef>
      <name>McastList</name>
      <synopsis>
      a PL level multicast list for ForCES multicast transport
      </synopsis>
      <struct>
          <element elementID="1">
             <name>groupID</name>

Hadi Salim               Expires Oct., 2006                [Page   10]
             <synopsis>32bits group ID of the multicast</synopsis>
             <typeRef>uint32</typeRef>
          </element>
          <element elementID="2">
             <name>members</name>
             <synopsis>
             members of the multicast represented by FE ID or CE ID
             </synopsis>
             <array>
                <typeRef>uint32</typeRef>
             </array>
          </element>
       </struct>
   </dataTypeDef>

   <attribute access="read-write" elementID="2">
     <name>McastLists</name>
     <synopsis>
     a table representing several multicast lists implementations. For instance, in the TML
     </synopsis>
     <array>
        <typeRef>McastList</typeRef>
     </array>
   </attribute>

   3) Working TML Type

   A TML implementation
     several cases, it may be capable of several TML transport ways.
   For example, a TML great help to associate with IP transport media some extra
     information as which CE/FE link is the congestion located. However,
     it may be able quite difficult for all TMLs and implementations to support
   several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In
   this case, there should be provide
     such information, therefore, as a more suitable choice, it is just
     left each TML attribute describing the different
   types and make PL able or implementation to switch among decide.

     More specific definitions of the three types under the control of
   CE.

   The TML type is represented by an ID, defined congestion alerts
     are presented as below:

   <dataTypeDef>
     <name>TMLType</name>
     <synopsis>TML Type</synopsis>
     <atomic>
       <typeRef>uint16</typeRef>
         <specialValues>
           <specialValue Value="1">
             <name>TmlTcpUdp</name>
             <synopsis>TML uses TCP+UDP</synopsis>
           </specialValue>
           <specialValue Value="2">
             <name>TmlTcpDccp</name>
             <synopsis>TML uses TCP+DCCP</synopsis>

Hadi Salim               Expires Oct., 2006                [Page   11]
           </specialValue>
           <specialValue Value="3">
             <name>TmlSctp</name>
             <synopsis>

     1. Congestion alert from control message transmission

     We define that ForCES control messages are all kinds of ForCES
     protocol messages but ForCES redirect messages. ForCES message types
     are identified by the message type in the ForCES message header.
     ForCES redirect messages are the messages whose types are marked as
     'PacketRedirect'[ForCES-PL]. ForCES redirect messages are used to
     load redirect data between FE and CE.

     Congestion alert from control message transmission indicates that TML
     is in a state where control message transmission channel is in danger
     of congestion and control messages is becoming hard to be transmitted
     to peering TML(s). Individual TML specifications or implementations
     may specifically define the detailed invoking state for the alert.

     Because ForCES control messages are vital for ForCES network elements
     to properly work, the congestion alert from control message
     transmission is an important signal for PL to timely take actions to
     secure the network element.

     2. Congestion alert from redirect message transmission

     This congestion alert is invoked when the TML comes to a risk that
     redirect messages are congested during transmission. Each TML
     specification or implementation may specifically define the detailed
     invoking state for the alert.

     ForCES redirect messages that load redirect data between FE and CE,
     congestion of which may not be so harmful as that of ForCES control
     messages, but some redirected data are still vital for ForCES network
     elements to properly work. For instance  routing protocol messages
     are shipped via ForCES redirect messages. A long time congestion of
     the messages will severely affect actions of routing protocols. Hence,
     this congestion alert should be used by PL to avoid redirect message
     congestion as much as possible to improve performance of whole
     network elements.

     3. Alert from redirect DoS attack

     As described, ForCES redirect messages ship redirect data. In FEs,
     redirect data come via FE interfaces from outer networks. This may
     leave a hole for malicious attackers [RFC3654, RFC3746]. Attackers
     may try to start a DoS attack by initiating huge amount of redirect
     data to some specific ForCES CE. It may make some FE TML abnormally
     busy transporting redirect data. Because TML channels for ForCES
     redirect messages and ForCES control messages are often intervened in
     many TML implementations in the same physical links, it may
     eventually making control messages transmission blocked by redirect
     messages transmission, making the network element in a denial of
     service state.

     This alert is used to indicate an alert for redirect DoS attack. Each
     TML specification or implementation will specifically define the
     actual invoking state or take a mechanism for the alert to be invoked,
     or make a justification if the TML is considered free from such DoS
     attack. If a TML has taken some specific mechanism to make
     straightforward detection of DoS attacks from redirect data, this
     alert may just be a result report of the DoS detection.

     The TML alert from redirect DoS attack may not be sufficient enough
     for the PL to assure the DoS attack state. PL may synthesize
     information from other part of the FE, like information from some FE
     LFBs, to finally decide it. Whereas, this alert has already been an
     enough signal for PL to go into some urgent state for the whole
     system security. Approaches should be taken immediately by PL to try
     to release the alert state so that the FE is not in a risk of losing
     control from CE.

  4.2.TML attributes

     TML attributes usually represent those TML parameters that need to be
     configured by PL. To represent them as TML attributes, PL can then
     use TML configuration service primitive as defined in Section 5.5 to
     make operations to the parameters. PL can then also use TML query
     service primitive defined in Section 5.6 to retrieve the status of
     the parameters.

     Every TML attribute shall be assigned with a unique id for PL to
     identify the attribute. The id is called TML attribute id.

     Followed are descriptions of basic TML attributes that shall be used
     by all TMLs. Each TML or implementation may provide more detailed
     definitions of these TML attributes based on the basic descriptions.
     Individual TMLs or implementations are also allowed to define more
     specific TML attributes on their own if necessary.

     1) TML event handle
     This TML attribute is used for PL to set some parameters for
     individual TML events. Each TML may individually define its data
     structure for this attribute, whereas, the data structure may have to
     appear as a list and every element of the list may have to at least
     include the following information:

     o TML event id
       This id acts as an index for individual TML events.

     o subscription flag, if described is a subscription-requested TML
     event
       This flag is to indicate the state for TML event subscription. To
     subscribe/unsubscribe an event is to set/reset the flag.

     The attribute may also include other information for each TML event
     implementation. For instance, for an implementation that adopts a
     callback mechanism for event notifications, the attribute may include
     a callback handle, which is used for PL to tell TML the callback
     function handle.

     The 'TML event handle' is assigned with a TML attribute id = 1.

     2) Multicast list

     ForCES protocol requires that TML must support for ForCES message
     delivery in multicast ways. This multicast is defined at ForCES PL
     level, i.e., to multicast a ForCES protocol message, a multicast
     'Destination ID' at the ForCES message header will be specified (See
     [ForCES-PL] for more details). To support the PL level multicast, TML
     must be told the members of the multicast, so that the TML can
     accordingly deliver messages to all the multicast members. A
     multicast list is used for this purpose. The multicast list comprises
     a multicast id, which is exactly the multicast 'Destination ID', and
     numerous associated members, which are also represented by ForCES
     'Destination ID's, represented as below:

       multicast list = {multicast id, member1, member2, ... memberN}

     When TML is told this multicast list, it means whenever TML is asked
     by PL to send a ForCES message whose Destination ID is this multicast
     id, the TML must deliver the message to all destination CEs or FEs
     whose ids are individually represented by member1, member2, ... , and
     memberN. Individual TML specifications should define how such
     multicast list maps to TML transport level multicast mechanisms. For
     instance, if TML adopts multiple TCP links for this PL level
     multicast, every member in the multicast list may be mapped to a
     specific TCP port and an associated IP address. If TML adopts UDP
     multicast for this PL level multicast, a UDP multicast group with the
     same numbers may be constructed and the multicast is mapped to the
     UDP multicast group.

     The multicast list must be set into TML by PL, hence it is defined
     as a TML attribute. PL sets up the attribute by use of a TML
     configuration service primitive.

     There might be several multicast lists set to a TML so as to
     construct multiple multicast paths for PL in this TML. The multicast
     lists may form a table then in the TML. In this case, a multicast id
     in every multicast list may act as an index for access of the table.

     The 'TML multicast list' is assigned with a TML attribute id = 2.

     3) Working TML Type

     A TML implementation may be capable of several TML transport ways.
     For example, a TML with IP transport media may be able to support TML
     schemes as TCP for control messages transmission and DCCP for
     redriect message transmission, or TCP for control messages and UDP
     for redirect messages. In this case, it may be helpful for PL to
     dynamically specify which TML transport scheme to adopt for current
     work.

     The working TML type is used for above purpose. It is defined as an
     TML attribute.

     It should be noted that, in many cases, PL does not have to manage
     working TML type. TML may more rely on its own management tool or a
     CE/FE manager for TML type management. As a result, this TML
     attribute is defined as an optional TML attribute, i.e., it is
     allowed that a TML may not provide this TML attribute for PL.

     Whereas if the attribute is provided, it should include the
     following information:

     o Working TML Type id
       the TML type represented by an id, which is set to the TML for it
     works in this type. The TML type id may be assigned with one of the
     following values:
       1 - an IP TML type with the protocol scheme as TCP+UDP, i.e., TCP
            for control message transmission and UDP for redirect data
            transmission.
       2 - an IP TML type with the protocol scheme as TCP+DCCP, i.e., TCP
            for control message transmission and DCCP for redirect data
            transmission.
       3 - an IP TML type with the protocol scheme as SCTP, i.e., SCTP for
            both control and redirect data transmissions.
       4 - an Ethernet TML type
       5  an ATM based TML type
     The 'Working TML type' is assigned with a TML attribute id = 3.

     4) TML media specific attributes

     An individual TML specification may require PL to configure some
     extra TML parameters specific to this TML media. If any, the TML
     specification shall provide detailed definitions for such attributes.

     5) Implementation specific TML attributes

     An individual TML implementation may require PL to configure some
     TML parameters specific to this implementation. If any, the
     individual implementation will provide detailed definitions for such
     attributes.

  4.3. TML capabilities

     TML capabilities represent TML abilities or capacities to provide
     services to PL. A TML capability can only be read by PL via TML query
     service primitive.

     Note that, the TML query service primitive as described in Section
     5.6 is used to query status of TML attributes as well as TML
     capabilities. A TML attribute id or a TML capability id is
     simultaneously used for the query operation. As a result, TML
     attribute id and TML capability id should be kept harmonious and
     unique to each other.

     1) Supported TML type

     PL may be interested to know what TML transportation type(s) the
     associated TML can support. A TML implementation may be capable of
     only one TML transport type or simultaneously several TML transport
     types. This TML capability indicates the relative information to PL.

     Note that, as mentioned before, in many cases, PL does not have to
     manage TML types. TML may more rely on its own management tool or the
     CE/FE managers for TML type management. As a result,  this capability
     is defined as an optional TML property, i.e., it is allowed some TML
     implementations may decide not to provide this information to PL.

     Whereas, if the capability is provided, it should include the
     following information:

     o a list of supported TML Type id(s)
       the TML Type id is as defined before.
     o configurable indicator
       a flag to indicate if the TML is configurable or not for its
     working type, i.e., if PL can use a working TML type attribute to set
     the type to the TML.

     The 'Supported TML type' capability is assigned with a TML
     capability id = 10.

  5. TML Service Primitives

  5.1.Design Principles

     The following principles are applied to the PL-TML service
     primitives design:

     1.PL-TML service primitives should hide implementation details
     regarding reliability, security, multicast, congestion control, etc
     from PL.

     2.PL-TML service primitives should be decoupled from possible
     changes of ForCES PL layer such as the update of ForCES protocol and
     ForCES FE model. More specifically, primitives should be avoided to
     be coupled with ForCES protocol PDU format.

  5.2.  TML Open

     Format:
        Result = TMLopen( )

     Result:
     the returned result; it shall indicate whether the TML open is
     succeeded or not. Moreover, if not succeeded, an id called 'TML id'
     and used to identify the TML should be returned by the primitive. If
     not succeeded, an error code may be returned to indicate the error
     type.

     Parameters:
     none

     Service Description:
     The primitive is for PL to indicate a TML that the PL is going to
     associate itself with the TML for services and hence the TML should
     be ready for use. It highly depends upon each TML specification or
     individual implementations on what a TML should do when it receives
     this primitive. For some TMLs, this primitive may just act as an
     indicator that the PL and the TML has been associated, while every
     thing for providing services has already been there in the TML. For
     other TMLs, when received the primitive, they may have to do
     something to make it ready. For example, for a TML that adopts a
     connectionless path as one of its transmission path, the path may
     always be ready for message transportation without any extra setup;
     while for a connection-oriented TML path, a TML open or a TML close
     (see below) primitive may act as an indicator for the TML path to be
     set or reset. However, it is also possible that some TML
     specifications or implementations may choose to have such connection-
     oriented path always ready for use when the TML has been initially
     booted.

     The 'TML id' returned by this primitive is as an identifier for the
     PL to recognize the TML. Other primitives as described below will use
     this id to identify a TML for operations. Having defined the TML id,
     we imply that the usage scenario as one PL being associated with more
     than one TML will not excluded by any TML specifications, and may be
     applied in actual implementations.

     An important note is, to better synchronize the operations between
     peering PLs, if a TML has, for any reason, received any PL messages
     from peering PL before local PL has formally opened the TML, the TML
     shall discard all these messages.

  5.3. TML close

     Format:
       Result = TMLclose(
                     TML id
                         )

     Result:
     the returned result; it shall indicate whether the TML close
     operation is succeeded or not. Moreover, if succeeded, an error code
     may be returned to indicate the error type for the failed TML close.

     Parameters:
     o TML id (input)
       the id of the TML to be closed.

     Service Description:
     By this primitive, a PL tears down its association with a TML. It
     highly depends upon each TML specification or implementation on what
     a TML should do when received this primitive. For some TMLs, this
     primitive may just act as an indication that the association of the
     PL and the TML is terminated and nothing more need to be done. For
     other TMLs, when received the primitive, they may have to manage to
     make it terminate the association, e.g., by disconnecting a
     connection with peering TML. However, it is out of scope of this
     document to have more details specified.

     An important note is, to better synchronize the operations between
     peer PLs, if a TML has, for any reason, received any PL messages from
     peer PL after local PL has formally closed the TML, the TML shall
     discard all these messages.

  5.4.TML Configuration

     Format:
         Result = TMLconfig(
                     TML id,
                     operation type,
                     TML attribute id,
                     TML attribute data
                     [,optional parameters]
                            )

     Result:
     the returned result; it shall indicate whether the TML configuration
     is succeeded or not. Moreover, if not succeeded, an error code may be
     returned to indicate the error type for the failed configuration.

     Parameters:
     o TML id (input)
       the id of the TML to be configured.
     o operation type (input)
       As an input parameter, it specifies the operation type the TML
     configuration primitive will do. The following operations must be
     included:
             SET  to set data to an attribute in the TML
             DELETE  to delete data from an attribute in the TML or to
     totally remove the attribute from the TML.
     The following operation may be included:
             MODIFY  to modify data for an attribute in the TML

     Individual TMLs or implementations may define other operations if
     necessary.

     o TML attribute id (input)
       the id inputted to TML; it uniquely specifies the TML attribute
     the primitive is going to operate on. The id is assigned by
     individual TML attribute definitions.

     o TML attribute data (input)
       a data unit that contains data elements to be configured to a TML
     attribute. Actual data structure of the data unit will be defined by
     individual TML implementations.

     o optional parameters (input or output):
       Individual TMLs or implementations may allow more parameters for
     the TML attribute configuration. For e.g., some implementations may
     choose to take an extra timeout parameter to make the primitive as a
     non-blocking primitive call. This document does not exclude such
     usages.

     Service Description:
     This primitive is used by PL to configure attributes of TML
     according to service requirements made to the TML. TML attributes are
     basically described as in Section 4.2. Every attribute to be operated
     is identified by the TML attribute id. The TML attribute data
     parameter provides necessary data for the operation. It is up to
     individual TML implementations to specify data structure for the
     attribute. It may be organized as an atomic data element or a
     compound data element. Individual TML implementations should provide
     detailed description on the data structure used for individual TML
     attributes.

     SET or DELETE operations are two basic operation types to a TML
     attribute operation. In some cases, more operation types may be
     required so that management to TML attributes may become more
     portable to users. This is especially useful for management of TML
     attributes like TML multicast lists. When PL configures multicast
     lists to TML, it may require some form of operation variations
     besides general operations as setting a new multicast list or
     deleting an existing multicast list. For instance, PL may be
     interested to add a member to, or delete a member from, an existing
     multicast list. There may be two approaches for each TML
     implementation to realize this. One is to define more types of
     operations. The other is to specifically associate attribute data
     structure definitions with operation types. Below is an example to
     show that this is feasible:

       o operation = SET, data = {multicast id, member1, member2, ...}
          If the multicast list with the multicast id does not exist in
     the TML, it is to set a new multicast list, or else, to add the new
     members as listed to the existing multicast list.

       o operation = DELETE, data = {multicast id }
         to delete the whole multicast list with the multicast id.

       o operation = DELETE, data = {multicast id, member1, member2, ...}
         to delete the members as listed from an existing multicast list,
     while keeping the multicast list id.

     Note that the TML uses SCTP</synopsis>
           </specialValue>
           <specialValue Value="4">
             <name>TmlEth</name>
             <synopsis>TML uses Ethernet</synopsis>
           </specialValue>
           <specialValue Value="5">
             <name>TmlAtm</name>
             <synopsis>TML uses ATM</synopsis>
           </specialValue>
         </specialValues>
     </atomic>
   </dataTypeDef> configuration service primitive is not designed to
     return any attribute status after configured. To check the TML
     attribute status, a TML query primitive as defined below should be
     specifically used.

  5.5. TML Query

     Format:
         Result = TMLquery(
                     TML id,
                     TML attribute id or TML capability id,
                     [,optional parameters]
                            )

     Result:
     The result includes a returned result and a queried result;

     The returned result shall indicate whether the primitive operation is
     succeeded or not. Moreover, if not succeeded, an error code may be
     returned to indicate the error type for the failed query operation.

     The queried result shall include the queried data if the query
     operation is succeeded. Each TML implementation shall define the data
     structure for the queried result data. Each TML attribute or TML
     capability may all have its specific data structure.

     Note that it is not specified and restricted how the queried result
     should be implemented in reality. Any techniques may be applied for
     this purpose under condition that the queried data can be transferred
     back to PL layer. For instance, some implementations may adopt a
     return of function call for transferring the queried result data,
     while some others may just adopt a parameter of function call for the
     transferring.

     Parameters:
     o TML id (input)
       the id of the TML to be operated.

     o TML attribute id or TML capability id (input)
       the id that uniquely specifies the TML attribute or TML capability
     the primitive is going to query.

     o optional parameters (input or output):
       Besides the mandatory parameters as presented, individual TMLs or
     implementations may adopt more parameters to customize the query
     operation. For instance, it may be interested to query a multicast
     list with a specified multicast id, rather than to query the whole
     existing multicast lists. This may be realized by defining a
     parameter composed of a multicast id as an index for the working TML type is defined query. The
     primitive may also include a timeout parameter to make the primitive
     as below:

   <attribute access="read-write read-only" elementID="3">
     <name>WorkingTMLType</name>
     <synopsis>current working TML type assigned a non-blocking operation. This document does not exclude such
     usages.

     Service Description:
     This primitive is used by PL </synopsis>
     <typeRef>TMLType</typeRef>
   </attribute>

   Note that, the working to query TML attributes or TML
     capabilities to know their current status. The TML type attribute may be configurable id or may
   only be readable depending on implementations.
     TML capability id is used to specify which attribute the primitive is
     interested to query. Queried data are included in result of the
     primitive execution. Note that this primitive definition does not
     specify any technology on how the queried data shall be transferred
     from TML type (defined below) will tell to PL, so as to make the primitive definition independent of
     any specific OS environments or implementation techniques.

  5.6. TML send

     Format:
       Result = TMLsend(
                      TML id,
                      message destination id,
                      message type,
                      message priority,
                      message length,
                      message PDU
                      [, timeout]
                      [, more optional parameters]
                        )

     Result:
     a returned code indicating if it the TML send primitive is configurable successful
     or not.  To
   query failed. If successful, a success code is returned. If failed, an
     error code indicating the failure type is returned.

     Parameters:
     o TML id (input)
       the id of the TML to be operated.

     o message destination id (input)
       the id indicating the destination of the ForCES PL message to be
     sent; equal to the destination ID in the protocol message header.

     o message type capability before configuring (input)
       the type of the ForCES protocol message to be sent; equal to the
     message type in the protocol message header.

     o message priority (input)
       the message priority of the protocol message to be sent; equal to
     the priority bits in the working TML type
   attribute will help protocol message header.

     o message length (input)
       the ForCES protocol message length to correctly configure it.

   4) Media specific TML parameters

   Individual TML may require configuring some TML parameters specific be sent, equal to its TML media. There leave a space the
     message length field in TML service primitives the protocol message header, representing the
     whole protocol message length in DWORDS ( 4 bytes) units.

     o message PDU (input)
       Protocol Data Unit for
   such requirement. the whole ForCES protocol message,
     including the message header and the body. Individual TML specifications should provide
   detailed definitions for such parameters.

   5) Vendor specific TML parameters

   Vendors of individual implementations of TML
     may require configuring
   some TML parameters specific need to its implementation. There leave further specify the endian way (big-endian or little-
     endian, etc).

     o timeout (input, optional parameter)
       This is an optional parameter to optionally specify the primitive
     as a
   space in TML service primitives for such requirement. Individual
   implementation should provide detailed definitions for such
   parameters.

4.3. TML capabilities

   1) Supported TML type

Hadi Salim               Expires Oct., 2006                [Page   12]
   A TML implementation non-blocking primitive call. The timeout value specifies how
     long it may be capable of several TML transport ways.
   This capability indicates PL wait before abortion of the supported types.

   The TML capability for primitive call. If not
     adopted, the supported TML type primitive is defined as below:

   <capability elementID="4">
     <name>SupportedTMLType</name>
     <synopsis>supported TML types executed in the TML mechanism</synopsis>
     <array type="variabl-size">
        <typeRef>TMLType</typeRef>
     </array>
   </capability>

   2) TML type configuration capability

   <capability elementID="5">
     <name>TMLTypeConfigurable</name>
     <synopsis>TML Type configurable a blocking way.

     o other optional parameters
       Individual TMLs or not by PL </synopsis>
     <typeRef>boolean</typeRef>
   </capability>

5. implementations may specify more optional
     parameters if necessary.

     Service Primitives

5.1.Design Principles

   Two principles are applied to description:
     By this PL-TML service primitives design:

   1.PL-TML service primitives should hide implementation details
   regarding reliability, security, multicast, congestion control, etc
   from PL.

   2.PL-TML service primitives should avoid leading TML service, PL tries to read ForCES
   protocol send a message PDU to get information, so as one (unicast) or more
     (multicast) peer PLs via the TML. Note that this primitive has
     explicitly included all information that are necessary for TML to immunize
     manage transmission of the PL message, therefore, there is no need
     for the TML
   from to further retrieve more information by reading the possible change PL
     message body PDU. In this way, it may be decoupled of changes in
     ForCES protocol PDU (like (e.g., by the protocol
   update).

5.2.Objectives

   There are several basic design objectives:

   1. Support for unicast, multicast and broadcast PL level mechanisms.
   2. support for both reliable and unreliable delivery.
   3. Support for in-order or agnostic delivery.
   4. Support for timeliness requirements.
   5. Support for both synchronous and asynchronous operations.
   6. Support for event notifications update) from TML to PL.

5.3.  TML Open

   Syntax:

Hadi Salim               Expires Oct., 2006                [Page   13]
     status =              -- SUCCESS or errorIndication
       TMLopen( )

   Parameters:
        none

   Service Description: services.

     The PL connects to the TML message destination id is used by invoking the TML open call. It highly
   depends on to map to TML layer
     transport addresses for the individual message transmission. This also includes
     the mapping of PL layer multicast ids to TML specifications what a layer multicast
     addresses. Each TML specification should do
   after receiving this call. For some TMLs, this primitive call may
   only act as a signal to inform TML that PL define the way for such
     mapping.

     The message type is going to use used for the TML
   for sending or receiving to infer the requirements from
     PL messages, while level for some other TMLs, a
   TML may have the message transmission, regarding its reliability,
     timeliness, security, and congestion control. With this message type,
     it is easy to do some recognize PL redirect messages from PL control messages.
     Individual TML level operation specifications shall define how the message types are
     mapped to prepare their individual transportation resources.

     The message priority is used for PL usage
   when receiving this primitive call. For example, For a connectionless
   TML, this open primitive may does not have the TML to do anything, while meet the PL requirement
     for
   a connection-oriented TML, this open call the message transmission priority; it may also be a signal used for the TML to setup
     meet the requirements for reliability, timeliness, security, and
     congestion control. Individual TML level connection(s) to peering TML(this actually means specifications may define how the peer-to-peer TMLs do not have
     priority is mapped to always their available transport mechanisms for
     prioritized timely transmission. Individual TML specifications may
     also define how the priority is used for other TML requirements.

     By use of an optional timeout parameter, the primitive may be connected after
     applied either in a blocking way or a non-blocking way.

  5.7. TML receive

     Format:
       Result = TMLreceive(
                      TML id,
                      message length,
                      message PDU,
                      timeout,
                      [, optional parameters]
                        )

     Result:
     a returned code indicating if the TML receive primitive is initialized and during
     successful or failed. If successful, a success code is returned. If
     failed, an error code indicating the post-association phase).

   Another important point is, to better synchronize failure type is returned.

     Parameters:
     o TML id (input)
       the operations
   between peering PLs, id of the TML will have to discard all be operated.

     o message length (output)
       the length of the PL messages received from peering PL before ForCES protocol message, representing
     the local whole protocol message length in DWORDS ( 4 bytes) units. It is a
     parameter output to PL by TML has not yet been opened via this primitive.

     o message PDU (output)
       Protocol Data Unit for the whole ForCES protocol message received,
     including the message header and the bogy. Individual implementations
     may need to specify the endian way (big-endian or little-endian, etc).
     It is a parameter output to PL by TML via this primitive.

     o timeout (input)
       This is a mandatory parameter for the local PL,

5.4. TML close

   Syntax:
     status =              -- SUCCESS or errorIndication
       TMLclose( )

   Parameters:
        none

   Service Description:
   In receive primitive. It
     mandates that the primitive shall work in a non-blocking way. The
     timeout value specifies how long it will mostly wait before abortion
     of this call, time receiving process.

     o optional parameters (input or output)
       Individual TMLs or implementations may specify more optional
     parameters for the primitive if necessary.

     Service description:
     This service is used for PL disconnects to synchronously receive ForCES protocol
     messages from the peering TML via local TML. It highly depends on A received protocol message
     is returned via the individual TML specifications what a TML parameters. The primitive specifies that it
     should do after be implemented in a non-blocking way. It is because that
     usually such receiving this call. For some TMLs, this primitive call process may only act
   as take high priority resources and a signal to inform TML
     blocking way may make the system risk more of fatal errors.

     Note that a message arrive event as described before can also be
     used for PL is not going to use the TML for
   sending or receiving receive PL messages anymore, while for some other TMLs,
   a TML may have to do some extra TML level operations to disconnect it
   to peering TMLs. For example, for a connectionless TML, from TML. The difference is that
     this TML receive primitive may do not have makes PL to do anything, synchronously receive messages,
     while for a connection-
   oriented TML, this primitive call may be message arrive event works in an asynchronous way receiving a signal for the TML to
   disconnect all TML level connections to peering TML.

   Another important point is, to better synchronize the operations
   between peering PLs,
     message. Usually, an asynchronous method exploits more efficiency in
     terms of CPU resources.

  6. Operation Notes
     1) multicast

     In a TML will have to discard all ForCES architecture, PL messages
   received by the TML after the TML has been closed by local PL.

Hadi Salim               Expires Oct., 2006                [Page   14]

5.5.TML Configuration

   Syntax:
     status =              -- SUCCESS or errorIndication
             TMLconfig(
                 IN  operation
                 IN  path
                 IN  data
                        )
   Parameters:

   operation ?the operation type for the configuration. Two operations
   are defined:
          operation = ADD ?to add parameter
                    = DELETE ?to delete parameter

   path ?a path composed of element ID(s) and (or) array index
   pointing to the element to level multicast may be configured.
   (TBD)

   data ?the data most commonly
     for a CE to be configured multicast a ForCES protocol message to multiple FEs.
     Operation steps for the element.
   (TBD)

   Service Description:
   This primitive is used by the PL ForCES system to control the behavior setup this type of the TML
   by the multicast
     may be presented as below:

     a. Before a PL layer configuring the related property elements level multicast could be established, usually a PL
     level unicast mechanism should first be established in the TML.
   The element is indicated by the 'path'. The value ForCES
     network element. This means a ForCES message should be able to be configured
     delivered in a unicast way between CE and FEs before we setup a
     multicast path.

     b. The CE PL (or its application layer) forms a PL level multicast
     list as defined in 2) of Section 4.2. Note that, because it
     represents multicast of a CE to FEs, the element is accessed by multicast list shall include
     a multicast id, the 'data'.

5.6. TML Query

   Syntax:
     status =              -- SUCCESS or errorIndication
             TMLquery(
                 IN  path
                 OUT data
                      )
   Parameters:

   path ?a path composed of element ID(s) CE id, and (or) array index
   pointing to the element to a number of member FE ids.

     c. The multicast list should be queried.
   (TBD)

   data ?the data returned by the query.
   (TBD)

   Service Description:

Hadi Salim               Expires Oct., 2006                [Page   15]
   This primitive is used by the PL sent to query the behavior of the TML.
   The querying element is indicated CE TML by the 'path'. The value queried is
   stored at the 'data' field. The TML executes the
     configuration service primitive as described by filling
   out the data field with the queried value of the element.

5.7. this document. When
     CE TML send

   Syntax:
     status =              -- SUCCESS or errorIndication
              TMLsend(
                  IN  msgDestID,
                  IN  msgType,
                  IN  msgPrio,
                  IN  msgLength,
                  IN  msgPDU,
                      )

   Parameters:
        msgDestID: the destination ID for receives this multicast list, the PL message TML is responsible to be sent
        msgType: the message type for map
     the PL message multicast list to be sent
        msgPrio: the message priority for the PL message its TML multicast mechanism.

     d. The multicast list may also need to be sent
        msgLen: the message length to be sent
        msgPDU: all FE members of
     the multicast by use of ForCES protocol message to be sent configure messages in its PDU

   Service Description:
   In this service, order
     for the PL sends a message FEs to know they belong to one (unicast) or more
   (multicast) peer PLs via the TML. Note that this primitive includes
   all parameters multicast group. Note that are necessary for TML to manage transmission a
     multicast list has been defined in FE as an attribute of the FE
     Protocol LFB [ForCES-PL]. The FEs further send the PL message, therefore, there is no need for multicast list
     to their FE TMLs by means of TML configuration primitive. When the
     FEs TMLs receive this multicast list, each TML is responsible to read in map
     the multicast list to its TML multicast mechanism.

     e. When a CE PL generates a message body with the multicast id as its
     destination id and sends it to retrieve this parameters. In this way, we may
   decouple changes in ForCES protocol PDU (e.g., by CE TML, the protocol update)
   from CE TML level.

   The msgDestID is used for the will use its TML
     level multicast mechanism to find out TML layer transport
   addresses for distribute the message transmission. It also includes messages to individual
     FEs in the
   processing for PL message multicast transports, for group.

     f. At the destination
   ID may also be FEs side, when a CE PL message with the multicast group ID.

   The msgType is used for id
     arrives at the FEs TMLs, each TML use its TML multicast mechanism to infer the requirements from PL
   level for
     accept the manage sending, regarding its reliability, timeliness,
   security, message, and congestion control. With this message type, further deliver it is easy to recognize PL redirect messages from PL control messages.
   Individual the FE PL.

     Above steps may vary in some way according to different TML types
     with their different mechanism supporting for TML specifications should define how level multicast.

     2) TBD

  7. Security Considerations
     The risk of being DoS attacked by redirect data has already been
     addressed by RFC 3654, RFC 3746, the msgTypes are used
   to map into ForCES protocol specification
     [ForCES-PL], etc. Prevention of the TML requirements.

   The msgPrio DoS attack is used for one of the TML key
     points to meet the PL requirement for secure the
   message transmission priority; it may also be used for ForCES system. This document specified a TML
     event notification of alert from redirect DoS attack to meet
   the specifically
     support a ForCES system to prevent such attack.

     TML requirements for reliability, timeliness, security, and congestion control. Individual TML specifications should define how

Hadi Salim               Expires Oct., 2006                [Page   16]
   the priority problem is mapped into the a broader point of view that may affect
     performance of a ForCES system greatly. A TML transport mechanisms for
   prioritized transmission. Individual event notification of
     TML specifications may also
   define how the priority congestion alert is used defined for other TML requirements.

5.8. by this document, so that TML receive

   Syntax:
     status =              -- SUCCESS or errorIndication
              TMLreceive(
                  IN  msgLength,
                  IN  msgPDU,
                         )

   Parameters:
        msgLen: the length
     primitives defined by this document is more capable of improvement of the message received.
        msgPDU: the received
     ForCES protocol message body in its PDU
   format

   Service Description: system performance.

     This service is used document does not define any mechanisms for PL to synchronously receive PL messages
   from peering TML.

   Note that a PL security services
     like endpoint authentication of FE and CE, message arrival event described before can also be
   used authentication,
     and confidentiality service This document just reaffirms the
     requirement for PL to receive PL messages from TML. The difference this security service. This is because that this TML receive primitive makes PL to synchronously receive messages,
   while a PL message arrival event receives messages in an asynchronous
   way. Usually, an asynchronous method is more efficient in terms kind
     of security requirement are all specific to TML specifications of
   CPU cycles.

6. Theory
     different TML media or individual implementations. Each TML
     specification shall provide detailed description on how to meet this
     requirement.

  8. Acknowledgements
     The authors would like to thank Joel M. Halpern, Huaiyuan Ma, et al
     for their invaluable comments during evolution of Operation

   (TBD)

7. the document.

  9. References

     [RFC3654] H. Khosravi, et al., Requirements for Separation of IP
     Control and Forwarding, RFC 3654, November 2003.

     [RFC3746] L. Yang, et al., Forwarding and Control Element Separation
     (ForCES) Framework, RFC 3746, April 2004.

     [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
     ietf-forces-protocol-08.txt, work-in-progress, Mar. 2006.

     [ForCES-Model] Yang, L., J. Halpern, E. Deleganes, ForCES Forwarding Element
     Model, Aug. 2003,
   http://www.ietf.org/internet-drafts/draft-ietf-forces-model-05.txt.

8. draft-ietf-forces-model-06.txt. work-in-progress, Oct. 2006.

  10. Author's Address

     Weiming Wang
     Zhejiang Gongshang University
     149 Jiaogong Road
     Hangzhou  310035

Hadi Salim               Expires Oct., 2006                [Page   17]
     P.R.China
     Phone: +86-571-88071024 +86-571-28877721
     EMail: wmwang@mail.zjgsu.edu.cn

     Jamal Hadi Salim
     Znyx Networks
     195 Stafford Rd. West
     Ottawa, Ontario
     Canada
     Phone:
     Email: hadi@znyx.com

Appendix A. TML Attributes XML file

   (TBD)

Intellectual Property

     Alex Audu
     Garland SoftWorx
     Garland, Texas
     USA

     Phone:
     Email: alex.audu@garlandnetworx.com

  Copyright Statement

     Copyright (C) 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 Trust (2007).

     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 is subject to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 rights, licenses and restrictions
     contained in BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 78, 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 except as set forth therein, the IETF at ietf-
   ipr@ietf.org.

Disclaimer of Validity 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 SOCIETY, THE
     IETF TRUST 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.

Hadi Salim               Expires Oct., 2006                [Page   18]

Copyright Statement

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

Acknowledgment

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

Hadi Salim               Expires Oct., 2006                [Page   19]