Internet DRAFT - draft-hadi-forces-tmlsp

draft-hadi-forces-tmlsp




   ForCES Working Group                                      W. M. Wang  
   Internet-Draft                              Zhejiang Gongshang Univ. 
   Expires: Augest, 2006                                  J. Hadi Salim 
                                                          Znyx Networks   
                                                              Feb. 2006 
     
    
           ForCES Transport Mapping Layer (TML) Service Primitives 
                            
                        draft-hadi-forces-tmlsp-00.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 Transport Mapping Layer 
   (TML) in a Forwarding and Control Element Separation(ForCES) network 

 
 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   element, to standardize the operations of ForCES Protocol Layer (PL) 
   to various types of TMLs.  
 
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]. 
 
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 
      4.1. TML events.................................................6 
      4.2. TML attributes.............................................9 
      4.3. TML capabilities..........................................13 
   5. Service Primitives.............................................13 
      5.1. Design Principles.........................................13 
      5.2. Objectives................................................13 
      5.3. TML Open..................................................14 
      5.4. TML close.................................................14 
      5.5. TML Configuration.........................................15 
      5.6. TML Query.................................................15 
      5.7. TML send..................................................16 
      5.8. TML receive...............................................17 
   6. Theory of Operation............................................17 
   7. References.....................................................17 
   8. Author's Address...............................................17 
   Appendix A. TML Attributes XML file...............................18 
  
 
1. Introduction 
 
   The Forwarding and Control Element Separation (ForCES) is a proposed 
   architecture for network elements like routers, documents of which 
   include RFC3654, RFC3746, and the ForCES protocol[ForCES-PL] and the 
   ForCES FE model[ForCES-Model] that are working in progress. RFC3654 
   defines the ForCES requirements, RFC3746 defines the ForCES framework, 
   and the ForCES protocol defines the message exchanging protocol 
   between the Forwarding Element (FE) and the Control Element (CE) in 
   the ForCES NE. 
    
   The ForCES protocol infrastructure constitutes of two components:  
    

 
Hadi Salim               Expires Augest, 2006                [Page  2] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   1.  The Protocol Layer (PL), which is responsible for generating 
   ForCES protocol messages and also processing protocol messages that 
   come from peering protocol layers in the same ForCES NE. 
    
   2.  The Transport Mapping Layer (TML), which is responsible for 
   ForCES protocol message transports over variant transport media like 
   IP, Ethernet, ATM, etc. 
    
   The ForCES protocol, which mainly define the PL, is being worked to 
   be standardized by IETF. TMLs according to various transport media 
   are also to be individually standardized by IETF. A ForCES PL 
   implementation must be portable across all TMLs. It makes feasible 
   that the implementers of TML and PL maybe from different 
   organizations. As a result, there must be a standard method to 
   interconnect PL and TML. A private method would make the PL and TML 
   implementations also private. 
    
   The purpose of this document is to present the method that 
   standardize the interconnection of PL and variant 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 are recommended for interconnection of PL and TML. 
   In this document, a set of TML Service Primitives are presented and 
   related TML parameters are defined. Also presented in the document is 
   the theory of operation of PL-TML based on the service primitives and 
   the parameters. 
    
2. Definitions 
    
   This document follows the terminology used by the ForCES 
   protocol[ForCES-PL]. Some 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 
 
Hadi Salim               Expires Augest, 2006                [Page  3] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
    
   The ForCES protocol has presented the protocol framework as in 
   Figure 1. The framework shows the relationship between PL and TML. 
   According to this framework, TML lies under PL and provides services 
   to the PL.  CE PL communicates with FE PL via CE TML and FE TML. On 
   transmit, the PL delivers its ForCES messages to the TML. The TML 
   further delivers the message to the destination TML(s). On receive, 
   the TML delivers the ForCES messages it received to the PL. 
    
    
               +----------------------------------------------- 
               |               CE PL layer                     | 
               +----------------------------------------------- 
               |              CE TML layer                     | 
               +----------------------------------------------- 
                                         ^ 
                                         | 
                               ForCES    |   
                               protocol  |   
                               messages  | 
                                         | 
                                         | 
                                         | 
                                         v 
               +----------------------------------------------- 
               |              FE TML layer                     | 
               +----------------------------------------------- 
               |               FE PL layer                     | 
               +----------------------------------------------- 
     
                                  Figure 1 
                                       
3.2. TML Requirements 
    
   The ForCES protocol [ForCES-PL] also presents 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 must 
   describe how it contributes to achieving the requirements. If for any 
   reason a TML does not provide a service listed below a justification 
   needs to be provided. 
    
   The TML requirements are: 
    
   1. Reliability 
   As defined by RFC 3654, section 6 #6. 
    
   2. Security 


 
Hadi Salim               Expires Augest, 2006                [Page  4] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   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 
    
          *  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  
    

 
Hadi Salim               Expires Augest, 2006                [Page  5] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   To make PL capable of interconnection with variant TMLs in a 
   standardized way, the first work to do is to model the variant TMLs 
   in a uniform way from the perspective of a uniform PL.  
    
   Identical to modeling an LFB in an FE, from the perspective of PL, 
   TML properties can be abstracted by the following entities: 
    
   TML Events: 
   The TML events that PL requires to know when the events happen in 
   the TML. 
    
   TML attributes: 
   The TML attributes that are required to be configured by PL 
   according to PL requirements. The attributes can also be queried by 
   PL. 
    
   TML capabilities: 
   The TML capabilities that PL are interested to know. 
    
   Note that, not all TML properties should be made perceivable by PL 
   from PL point of view. PL only cares those TML properties that are 
   common to all TMLs and that PL should interact with via service 
   primitives so that TML can work according to PL's requirements.  
    
   Via TML Service Primitives, PL should be able to access above 
   properties of variant TMLs.  
    
4.1.TML events 
    
   There might be several TML events, but only some of them are PL must 
   sense via PL-TML interface.  
    
   A callback mechanism is defined for PL to sense the TML events by 
   PL-TML service primitives. PL first provides every event with a 
   callback function for the event processing in the PL. PL then tells 
   the callback handle to TML by service primitives. The callback handle 
   is usually stored in TML as a parameter. Whenever the relavent event 
   happens in TML, the TML triggers the handle to notify PL of the event. 
   PL executes the callback function, and asynchronously begins to 
   process the event. 
    
   After a TML event happened and PL is notified and a procedure to 
   process the event is executed, PL may be further interested in 
   knowing if the event status in the TML still exists or not. To meet 
   this requirement, an 'eventState' parameter is used in callback 
   functions to indicate if the reported is the event happened or the 
   event released. Whereas, not all events need to notify PL of their 
   release state. 
    

 
Hadi Salim               Expires Augest, 2006                [Page  6] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   The following TML events must be made to be notified by PL. If for 
   any reason a TML does not provide the service, a justification needs 
   to be provided in the TML specification. 
    
   1) TML failure event 
    
   This event happens when there is a TML failure. It is up to 
   individual TML specifications and even individual implementations to 
   specify the detailed event triggering conditions, but usually, TML 
   failure should include the following cases: 
   . local TML link failure 
   . peer TML unavailable 
   . peer TML left 
    
   The different cases that cause the failure will be stated by a 
   failure code in the event callback function. 
    
   Callback handle for TML failure event is then defined as: 
    
     status =              -- SUCCESS or errorIndication 
              callbackTMLFailureEvent( 
                        IN   eventState 
                        IN   failCode  
                                      ) 
   Where, 
        eventState = EventHAPPENED or EventRELEASED  
        failCode indicates the failure case 
     
   2) Message arrival event 
    
   TML can make it as an event when a PL ForCES protocol message coming 
   from peering TML arrives at the TML and the TML has made it ready for 
   PL to receive the message. 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) for synchronous reception of PL messages.  
    
   Callback handle for message arrival event is defined as: 
    
     status =              -- SUCCESS or errorIndication 
              callbackTMLMsgArrivalEvent( 
                           IN   msglen 
                           IN   msgPDU  
                                         ) 
   Where, msglen indicates the ForCES message length, and msgPDU is the 
   ForCES message body in its Protocol Data Unit format. There is no 
   need for message arrival event to notify a release state.  
    
   3) Control message congestion event 
    
 
Hadi Salim               Expires Augest, 2006                [Page  7] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   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 event happens when the TML comes to a congestion state for the 
   control message transmission. It is up to individual TML 
   specifications and even individual implementations to specify the 
   detailed event triggering conditions.  
    
   This event can be used by PL layer to monitor the control message 
   transmission. In FEs, this event may also be used to help monitoring 
   possible DoS attacks from redirected packets.  
    
   Callback handle for TML control message congestion event is defined 
   as: 
    
     status =              -- SUCCESS or errorIndication 
              callbackTMLCtrMsgCongestEvent( 
                            IN   eventState 
                                            ) 
   Where, 
        eventState = EventHAPPENED or EventRELEASED  
    
   4)Redirect message congestion event 
    
   This event happens when the TML comes to a congestion state for the 
   PL redirect message transmission. It is up to individual TML 
   specifications and even individual implementations to specify the 
   detailed event triggering conditions.  
    
   This event can be used by PL layer to monitor the redirect message 
   transmission. In FEs, this may also be used to help monitoring 
   possible DoS attacks from redirect packets. 
    
   Callback handle for TML redirect message congestion event is defined 
   as: 
    
     status =              -- SUCCESS or errorIndication 
              callbackTMLRedMsgCongestEvent( 
                              IN   eventState 
                                            ) 
   Where, 
        eventState = EventHAPPENED or EventRELEASED  
    
   5)DoS attack alert event 
    
   This event happens when the TML comes to a state that it feels there 
   are abnormal amount of PL redirect messages and there has made it 
   quite hard to transport PL control messages. Whereas, it is up to 
 
Hadi Salim               Expires Augest, 2006                [Page  8] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   individual TML specifications and even individual implementations to 
   specify the detailed and precise triggering conditions for the event.  
    
   This event is used by PL to monitor the security state for TML 
   message transmission. In FEs, when this event happens, usually FE PL 
   should trigger a DoS attack alert event to inform CE of the event. CE 
   may take further effects trying to prevent the attack. Note that, the 
   event 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 PL to access events. An event callback 
   function handle is used as the purpose. Defining the handles as an 
   attribute of the TML, then, for PL to set the handle to TML is for 
   the PL to subscribe to the TML for the event notification, to delete 
   the handle from the TML is to unsubscribe the event from the TML. 
    
   We define the event handle TML attribute as below: 
    
   <dataTypeDef> 
     <name>Eventhandle</name>  
     <synopsis>Event callback handle</synopsis>  
     <struct> 
       <element elementID="1"> 
         <name>eventType</name>  
         <synopsis>event type represented by an ID </synopsis>  
         <typeRef>uint16</typeRef>  
         <specialValues> 
           <specialValue Value=?? 
             <name>TMLFailureEvent</name>  
             <synopsis>TML failure event</synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TMLMsgArrivalEvent</name>  
             <synopsis>TML ForCES message arrival event</synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TMLCtrMsgCongestEvent</name>  
 
Hadi Salim               Expires Augest, 2006                [Page  9] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
             <synopsis> 
             TML ForCES congtrol message transmit congestion event 
             </synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TMLRedMsgCongestEvent</name>  
             <synopsis> 
             TML ForCES redirect message transmit congestion event 
             </synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TMLDoSAttackAlertEvent</name>  
             <synopsis>TML 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=?? 
     <name>EventHandles</name> 
     <synopsis>event handle table in the TML</synopsis> 
     <array> 
        <typeRef>EventHandle</typeRef> 
     </array> 
   </attribute> 
    
   2)multicast lists 
    
   This attribute is used for TML to multicast ForCES messages. The 
   multicast list should be configured by PL, but 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> 
 
Hadi Salim               Expires Augest, 2006                [Page 10] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
      <name>McastList</name>  
      <synopsis> 
      a PL level multicast list for ForCES multicast transport 
      </synopsis>  
      <struct> 
          <element elementID="1"> 
             <name>groupID</name>  
             <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=?? 
     <name>McastLists</name> 
     <synopsis> 
     a table representing several multicast lists in the TML 
     </synopsis> 
     <array> 
        <typeRef>McastList</typeRef> 
     </array> 
   </attribute> 
    
    
   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 
   several transport protocols, like TCP+UDP, TCP+DCCP, SCTP, etc. In 
   this case, there should be a TML attribute describing the different 
   types and make PL able to switch among the types under the control of 
   CE. 
    
   The TML type is represented by an ID, defined as below: 
    
   <dataTypeDef> 
     <name>TMLType</name>  
     <synopsis>TML Type</synopsis> 
     <atomic> 
       <typeRef>uint16</typeRef>  
         <specialValues> 
 
Hadi Salim               Expires Augest, 2006                [Page 11] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
           <specialValue Value=?? 
             <name>TmlTcpUdp</name>  
             <synopsis>TML uses TCP+UDP</synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TmlTcpDccp</name>  
             <synopsis>TML uses TCP+DCCP</synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TmlSctp</name>  
             <synopsis> TML uses SCTP</synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TmlEth</name>  
             <synopsis>TML uses Ethernet</synopsis>  
           </specialValue> 
           <specialValue Value=?? 
             <name>TmlAtm</name>  
             <synopsis>TML uses ATM</synopsis>  
           </specialValue> 
         </specialValues> 
     </atomic> 
   </dataTypeDef> 
    
   The TML attribute for the working TML type is defined as below:  
    
   <attribute access=”read-write read-only?elementID=?? 
     <name>WorkingTMLType</name> 
     <synopsis>current working TML type assigned by PL </synopsis> 
     <typeRef>TMLType</typeRef> 
   </attribute> 
    
   Note that, the working TML type attribute may be configurable or may 
   only be readable depending on implementations. TML capability on the 
   TML type (defined below) will tell if it is configurable or not.  To 
   query the TML type capability before configuring the working TML type 
   attribute will help to correctly configure it.  
    
   4) Media specific TML parameters 
    
   Individual TML may require configuring some TML parameters specific 
   to its TML media. There leave a space in TML service primitives for 
   such requirement. 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 to its implementation. There leave a 
   space in TML service primitives for such requirement. Individual 
 
Hadi Salim               Expires Augest, 2006                [Page 12] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   implementation should provide detailed definitions for such 
   parameters. 
    
4.3. TML capabilities 
    
   1) Supported TML type 
    
   A TML implementation may be capable of several TML transport ways. 
   This capability indicates PL of the supported types.  
    
   The TML capability for the supported TML type is defined as below:  
    
   <capability elementID=?? 
     <name>SupportedTMLType</name> 
     <synopsis>supported TML types in the TML mechanism</synopsis> 
     <array type=”variabl-size? 
        <typeRef>TMLType</typeRef> 
     </array> 
   </capability> 
    
   2) TML type configuration capability 
    
   <capability elementID=?? 
     <name>TMLTypeConfigurable</name> 
     <synopsis>TML Type configurable or not by PL </synopsis> 
     <typeRef>boolean</typeRef> 
   </capability> 
    
5. Service Primitives 
    
5.1.Design Principles 
     
   Two principles are applied to 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 to read ForCES 
   protocol message PDU to get information, so as to immunize the TML 
   from the possible change of ForCES protocol PDU (like 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. 
 
Hadi Salim               Expires Augest, 2006                [Page 13] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   4. Support for timeliness requirements. 
   5. Support for both synchronous and asynchronous operations. 
   6. Support for event notifications from TML to PL. 
    
5.3.  TML Open  
     
   Syntax: 
     status =              -- SUCCESS or errorIndication 
       TMLopen( ) 
    
   Parameters: 
        none  
    
   Service Description: 
   The PL connects to the TML by invoking the TML open call. It highly 
   depends on the individual TML specifications what a TML should do 
   after receiving this call. For some TMLs, this primitive call may 
   only act as a signal to inform TML that PL is going to use the TML 
   for sending or receiving PL messages, while for some other TMLs, a 
   TML may have to do some TML level operation to prepare for PL usage 
   when receiving this primitive call. For example, For a connectionless 
   TML, this open primitive may does not have to do anything, while for 
   a connection-oriented TML, this open call may be a signal for the TML 
   to setup TML level connection(s) to peering TML(this actually means 
   the peer-to-peer TMLs do not have to always be connected after the 
   TML is initialized and during the post-association phase). 
     
   Another important point is, to better synchronize the operations 
   between peering PLs, the TML will have to discard all the PL messages 
   received from peering PL before the local TML has not yet been opened 
   by the local PL,  
    
5.4. TML close 
     
   Syntax: 
     status =              -- SUCCESS or errorIndication 
       TMLclose( ) 
    
   Parameters: 
        none 
    
   Service Description: 
   In this call, the PL disconnects from the TML. It highly depends on 
   the individual TML specifications what a TML should do after 
   receiving this call. For some TMLs, this primitive call may only act 
   as a signal to inform TML that PL is not going to use the TML for 
   sending or receiving 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, this 
   primitive may do not have to do anything, while for a connection-
 
Hadi Salim               Expires Augest, 2006                [Page 14] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   oriented TML, this primitive call may be 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, a TML will have to discard all PL messages 
   received by the TML after the TML has been closed by local PL. 
    
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 be configured.  
   (TBD) 
    
   data ?the data to be configured to the element. 
   (TBD) 
         
   Service Description: 
   This primitive is used by the PL to control the behavior of the TML 
   by the PL layer configuring the related property elements in the TML. 
   The element is indicated by the 'path'. The value to be configured to 
   the element is accessed by 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) and (or) array index 
   pointing to the element to be queried.  
   (TBD) 
    
 
Hadi Salim               Expires Augest, 2006                [Page 15] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   data ?the data returned by the query. 
   (TBD) 
    
    
   Service Description: 
    
   This primitive is used by the PL to query the behavior of the TML. 
   The querying element is indicated by the 'path'. The value queried is 
   stored at the 'data' field. The TML executes the primitive by filling 
   out the data field with the queried value of the element. 
    
    
5.7. TML send 
    
   Syntax: 
     status =              -- SUCCESS or errorIndication 
              TMLsend( 
                  IN  msgDestID, 
                  IN  msgType, 
                  IN  msgPrio, 
                  IN  msgLength, 
                  IN  msgPDU, 
                      ) 
    
   Parameters: 
        msgDestID: the destination ID for the PL message to be sent 
        msgType: the message type for the PL message to be sent 
        msgPrio: the message priority for the PL message to be sent 
        msgLen: the message length to be sent 
        msgPDU: the ForCES protocol message to be sent in its PDU   
      
   Service Description: 
   In this service, the PL sends a message to one (unicast) or more 
   (multicast) peer PLs via the TML. Note that this primitive includes 
   all parameters that are necessary for TML to manage transmission of 
   the PL message, therefore, there is no need for the TML to read in 
   the PL message body to retrieve this parameters. In this way, we may 
   decouple changes in ForCES protocol PDU (e.g., by the protocol update) 
   from TML level.  
    
   The msgDestID is used for the TML to find out TML layer transport 
   addresses for the message transmission. It also includes the 
   processing for PL message multicast transports, for the destination 
   ID may also be a multicast group ID.  
    
   The msgType is used for the TML to infer the requirements from PL 
   level for the manage sending, regarding its reliability, timeliness, 
   security, and congestion control. With this message type, it is easy 
   to recognize PL redirect messages from PL control messages. 

 
Hadi Salim               Expires Augest, 2006                [Page 16] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   Individual TML specifications should define how the msgTypes are used 
   to map into the TML requirements. 
    
   The msgPrio is used for the TML to meet the PL requirement for the 
   message transmission priority; it may also be used for TML to meet 
   the TML requirements for reliability, timeliness, security, and 
   congestion control. Individual TML specifications should define how 
   the priority is mapped into the TML transport mechanisms for 
   prioritized transmission. Individual TML specifications may also 
   define how the priority is used for other TML requirements. 
    
5.8. TML receive 
    
   Syntax: 
     status =              -- SUCCESS or errorIndication 
              TMLreceive( 
                  IN  msgLength, 
                  IN  msgPDU, 
                         ) 
    
   Parameters: 
        msgLen: the length of the message received. 
        msgPDU: the received ForCES protocol message body in its PDU 
   format 
    
   Service Description: 
   This service is used for PL to synchronously receive PL messages 
   from peering TML.  
    
   Note that a PL message arrival event described before can also be 
   used for PL to receive PL messages from TML. The difference is 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 of 
   CPU cycles.  
    
6. Theory of Operation 
    
   (TBD) 
    
7. References 
    
   [ForCES-PL] A. Doria, et al., ForCES protocol specifications, draft-
   ietf-forces-protocol-06.txt, work-in-progress, Dec. 2005.  
    
   [ForCES-Model] Yang, L., "ForCES Forwarding Element Model", Aug. 
   2003, http://www.ietf.org/internet-drafts/draft-ietf-forces-model-
   05.txt. 
    
8. Author's Address 
 
Hadi Salim               Expires Augest, 2006                [Page 17] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
    
   Weiming Wang 
   Zhejiang Gongshang University 
   149 Jiaogong Road 
   Hangzhou  310035 
   P.R.China 
   Phone: +86-571-88071024 
   EMail: wmwang@mail.zjgsu.edu.cn 
    
   Jamal Hadi Salim 
   Znyx Networks 
   195 Stafford Rd. West 
   Ottawa, Ontario 
   Canada 
   Email: hadi@znyx.com  
    
Appendix A. TML Attributes XML file 
    
   (TBD) 
    
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 
 
Hadi Salim               Expires Augest, 2006                [Page 18] 
Internet Draft              ForCES TML SP                   Feb. 2005 
 
 
   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 (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 Augest, 2006                [Page 19]