Network Working Group                                      J. Hadi Salim
Internet-Draft                                             ZNYX Networks
Expires: May 12, 2008 January 15, 2009                                       K. Ogawa
                                                         NTT Network Service Systems
                                                        November 9, 2007 Corporation
                                                           July 14, 2008

      SCTP based TML (Transport Mapping Layer) for ForCES protocol

Status of this Memo

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

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

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 12, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). January 15, 2009.


   This document defines the SCTP based TML (Transport Mapping Layer)
   for the ForCES protocol.  It explains the rationale for choosing the
   SCTP (Stream Control Transmission Protocol) [RFC2960] and also
   describes how this TML addresses all the requirements described in
   [RFC3654] and the ForCES protocol [FE-PROTO] draft.

Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Framework Overview  . . . . . . . . . . . . . . . . .  3
     3.1.  The PL . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.2.  The TML layer  . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1.  TML Parameterization . . . . . . . . . . . . . . . . .  6
     3.3.  The TML-PL interface . . . . . . . . . . . . . . . . . . .  6
   4.  SCTP TML overview  . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Introduction to SCTP . . . . . . . . . . . . . . . . . . .  7
     4.2.  Rationale for using SCTP for TML . . . . . . . . . . . . .  9
     4.2.  Meeting TML requirements . . . . . . . . . . . . . . . . .  9
       4.3.1.  Reliability  . . . . . 10
       4.2.1.  SCTP TML Channels  . . . . . . . . . . . . . . . . 10
       4.3.2.  Congestion control . . 11
       4.2.2.  Satisfying Reliability Requirement . . . . . . . . . . 13
       4.2.3.  Satisfying Congestion Control Requirement  . . . . . . 10
       4.3.3. 13
       4.2.4.  Satisfying Timeliness and prioritization  . . . prioritizationi
               Requirement  . . . . . . . . . 10
       4.3.4.  Addressing . . . . . . . . . . . . 13
       4.2.5.  Satisfying Addressing Requirement  . . . . . . . . . . 10
       4.3.5. 14
       4.2.6.  Satisfying HA Requirement  . . . . . . . . . . . . . . 14
       4.2.7.  Satisfying DOS Prevention Requirement  . . . . . . . . . . . . 10
       4.3.6.  DOS prevention 14
       4.2.8.  Satisfying Encapsulation Requirement . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . 11
       4.3.7.  Encapsulation . . . . . . . . . . 15
   6.  Security Considerations  . . . . . . . . . . 11
   5.  IANA Considerations . . . . . . . . . 15
     6.1.  TLS Usage for Securing TML . . . . . . . . . . . . 11
   6.  Security Considerations . . . . 15
     6.2.  IPSec Usage for securing TML . . . . . . . . . . . . . . . 11 15
   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 11 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 12 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 14 18

1.  Definitions

   The following definitions are taken from [RFC3654]and [RFC3746]:

   ForCES Protocol -- The protocol used at the Fp reference point in the
   ForCES Framework in [RFC3746].

   ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
   architecture that defines the ForCES protocol architecture and the
   state transfer mechanisms as defined in [FE-PROTO].

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

2.  Introduction

   The ForCES (Forwarding and Control Element Separation) working group
   in the IETF is defining the architecture and protocol for separation
   of control Control Elements(CE) and forwarding elements Forwarding Elements(FE) in network elements Network
   Elements(NE) such as routers.  [RFC3654] and [RFC3746] respectively
   define architectural and protocol requirements for the communication
   between CE and FE.  The ForCES protocol layer specification
   [FE-PROTO] describes the protocol semantics and workings.  The ForCES
   protocol layer operates on top of an inter-connect hiding layer known
   as the TML.  The relationship is illustrated in Figure 1.

   This document defines the SCTP based TML for the ForCES protocol
   layer.  It also addresses all the requirements for the TML including
   security, reliability, etc as defined in [FE-PROTO].

   XXXX: TBD - a reference to the correct document for a more complete
   list of terminology.

3.  Protocol Framework Overview

   The reader is referred to the Framework document [RFC3746], and in
   particular sections 3 and 4, for an architectural overview and
   explanation of where and how the ForCES protocol fits in.

   There is some content overlap between the ForCES protocol draft
   [FE-PROTO] and this section in order to provide clarity. clarity to the reader
   of this document.

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


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

      Figure 1: Message exchange between CE and FE to establish an NE

   The PL layer is in charge of the ForCES protocol.  Its semantics and
   message layout are defined in [FE-PROTO].  The TML Layer is necessary
   to connect two ForCES PL layers as shown in Figure 1.

   Both the PL and TML are standardized by the IETF.  While only one PL
   is defined, different TMLs are expected to be standardized.  The TML
   at each of the peers (CE and FE) is expected to be of the same
   definition in order to inter-operate.

   When transmitting, the PL delivers its messages to the TML.  The TML
   then delivers the PL message to the destination peer TML(s) as
   defined by the addressing in the PL message.

   On reception of a message, the TML delivers the message to its
   destination PL layer(s). layer(s) (as described in the ForCES header).

3.1.  The PL

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

3.2.  The TML layer

   The TML layer is responsible for transport of the PL layer messages.
   The TML provides the following services on behalf of the ForCES

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

   2.  Security
       TML provides security services to the ForCES PL.  The TML
       definition needs to define how the following are achieved:

       *  Endpoint authentication of FE and CE

       *  Message authentication

       *  Confidentiality service

   3.  Congestion Control
       The congestion control mechanism defined by the TML should
       prevent the FE from being overloaded by the CE.  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.  Transport High Availability
       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 allow for this.

   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
       The TML SHOULD will be able to handle up to 8 priority levels
       needed by the PL and will provide preferential treatment.
       The TML needs to define how this is achieved.

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

   It is expected more than one TML will be standardized.  The different
   TMLs each could implement things differently based on capabilities of
   underlying media and transport.  However, since each TML is
   standardized, interoperability is guaranteed only as long as both
   endpoints support the same TML.

3.2.1.  TML Parameterization

   It is expected that it should be possible to use a configuration
   reference point, such as the FEM or the CEM, to configure the TML.

   Some of the configured parameters may include:

   o  PL ID

   o  Connection Type and associated data.  For example if a TML uses
      IP/TCP/UDP then parameters such as TCP and UDP ports and IP
      addresses need to be configured.

   o  Number of transport connections

   o  Connection Capability, such as bandwidth, etc.

   o  Allowed/Supported Connection QoS policy (or Congestion Control

3.3.  The TML-PL interface

   [TML-API] defines an interface between the PL and the TML layers.
   The end goal of [TML-API] is to provide a consistent top edge
   semantics for all TMLs to adhere to.  Conforming to such an interface
   makes it easy to plug in different TMLs over time.  It also allows
   for simplified TML parameterization requirement stated in
   Section 3.2.1.


                  |                      |
                  |       PL Layer       |
                  |                      |
                  |........ .............|
                             |   TML API
                  |                      |
                  |       TML Layer      |
                  |                      |

                      Figure 2: The TML-PL interface

   We are going to assume the existence of such an interface and not
   discuss it further.  The reader is encouraged to read [TML-API] as a

   Editorial Note: There is some concern (and confusion) about defining
   APIs in ForCES.  So at the moment the future of [TML-API] is unknown
   (unless these concerns are cleared).

4.  SCTP TML overview

4.1.  Introduction to SCTP

   SCTP [RFC2960] is an end-to-end transport protocol that is equivalent
   to TCP, UDP, or DCCP in many aspects.  With a few exceptions, SCTP
   can do most of what UDP, TCP, or DCCP can achieve.  SCTP as well can
   do most of what a combination of the other transport protocols can
   achieve (eg TCP and DCCP or TCP and UDP).

   Like TCP, it provides ordered, reliable, connection-oriented, flow-
   controlled, congestion controlled data exchange.  Unlike TCP, it does
   not provide byte streaming and instead provides message boundaries.

   Like UDP, it can provide unreliable, unordered data exchange.  Unlike
   UDP, it does not provide multicast support
   Like DCCP, it can provide unreliable, ordered, congestion controlled,
   connection-oriented data exchange.

   SCTP also provides other services that none of the 3 transport
   protocols mentioned above provide.  These include:

   o  Multi-homing
      An SCTP connection can make use of multiple destination IP
      addresses to communicate with its peer.

   o  Runtime IP address binding
      With the SCTP ADDIP feature, a new address can be bound at
      runtime.  This allows for migration of endpoints without
      restarting the association (valuable for high availability).

   o  A range of reliability shades with congestion control
      SCTP offers a range of services from full reliability to none, and
      from full ordering to none.  With SCTP, on a per message basis,
      the application can specify a message's time-to-live.  When the
      expressed time expires, the message can be "skipped".

   o  Built-in heartbeats
      SCTP has built-in heartbeat mechanism that validate the
      reachability of peer addresses.

   o  Multi-streaming
      A known problem with TCP is head of line (HOL) blocking.  If you
      have independent messages, TCP enforces ordering of such messages.
      Loss at the head of the messages implies delays of delivery of
      subsequent packets.  SCTP allows for defining upto 64K independent
      streams over the same socket connection, which are ordered

   o  Message boundaries with reliability
      SCTP allows for easier message parsing (just like UDP but with
      reliability built in) because it establishes boundaries on a PL
      message basis.  On a TCP stream, one would have to peek use techniques
      such peeking into the message to figure the boundaries.

   o  Improved SYN DOS protection
      Unlike TCP, which does a 3 way connection setup handshake, SCTP
      does a 4 way handshake.  This improves against SYN-flood attacks
      because listening sockets do not set up state until a connection
      is validated.

   o  Simpler transport events
      An application (such as the TML) can subscribe to be notified of
      both local and remote transport events.  Events such as that can be
      subscribed-to include indication of association changes,
      addressing changes, remote errors, expiry of timed messages, etc, etc.
      These events are off by default and require explicit subscription.

   o  Simplified replicasting
      Although SCTP does not allow for multicasting it allows for a
      single message from an application to be sent to multiple peers.
      This reduces the messaging that typically crosess different memory
      domains within a host.


4.1.  Rationale for using SCTP for TML

   SCTP has all the features required to provide a robust TML.  As a
   transport that is all-encompassing, it negates the need for having
   multiple transport protocols, as has been suggested so far in the
   other proposals for TMLs.  As a result it allows for simpler coding
   and therefore reduces a lot of the interoperability concerns.

   SCTP is also very mature and widely deployed completing the equation
   that makes it a superior choice in comparison with other proposed


4.2.  Meeting TML requirements


                  |                     |
                              |     PL   TML API
                   TML        |
                  |           |
                  |........ .+.........|          |
                             +   TML API
                  ,''''''''''+'''''''''`.    +------+------+   |
                  |    |  TML core   |   |
                  |    +-+----+----+-+   |
                  |      |    |    |     |
                             +    SCTP socket API   |
                  |      |    |    |     |
                  |      |    |    |     |
                  |    +-+----+----+-+   |
                  |    |    SCTP     |   |       (over IP)
                  |    +------+------+   |
                  |           |          |
                  |           |          |
                  |    +------+------+   |
                  |    |      IP     |   |
                  |    +-------------+   |

                     Figure 3: The TML-SCTP interface

   Figure 3 above shows details the interfacing between the TML and SCTP.  There
   is only one socket connection open with two streams used.  The first
   stream which is high priority will be dedicated for configuration
   data SCTP and the second lower priority stream is used for data path
   internals of the SCTP TML.  The TML will use information passed by core of the TML API interfaces on its
   north bound interface to
   select which of the two streams to use when sending.  The PL (utilizing the TML will
   also subscribe to API).  On the
   southbound interface, the TML core interfaces to the SCTP layer
   utilizing the standard socket interface [Editorial: add here a
   reference to SCTP Sockets API doc].  There are three SCTP socket
   connections opened between any two PL layers (whether FE or CE).

4.2.1.  SCTP TML Channels

                  |                    |
                  |     TML   core     |
                  |                    |
                    |       |        |
                    |   Med prio,    |
                    |  Semi-reliable |
                    |    channel     |
                    |       |      Low prio,
                    |       |      Unreliable channel
                    |       |        |
                    ^       ^        ^
                    |       |        |
                    Y       Y        Y
          High prio,|       |        |
           reliable |       |        |
            channel |       |        |
                    Y       Y        Y
                 |                     |
                 |        SCTP         |
                 |                     |

                      Figure 4: The TML-SCTP channels

   Figure 4 details further the interfacing between the TML core and
   SCTP layers.  There are 3 channels used to separate and prioritize
   the different types of ForCES traffic.  Each channel constitutes a
   socket interface.  It should be noted that all SCTP channels are
   congestion aware (and for that reason that detail is left out of the
   description of the 3 channels).  SCTP port 6700, 6701, 6702 are used
   for the higher, medium and lower priority channels respectively.  Justifying Choice of 3 Sockets

   SCTP allows upto 64K streams to be sent over a single socket
   interface.  The authors initially envisioned using a single socket
   for all three channels (mapping a channel to an SCTP stream).  This
   simplifies programming of the TML as well as conserves use of SCTP

   Further analysis revealed head of line blocking issues with this
   initial approach.  Lower priority packets not needing reliable
   delivery could block higher priority packets (needing reliable
   delivery) under congestion situation.  This proposal alleviates that
   problem by making the medium and low priority channels obsolete over
   a period of time, but that is still insufficient to resolve the
   outstanding HOL issue.

   XXX: Talk here about Michael Tuxen's approach which will allow for
   SCTP to prioritize streams within a single socket.  Unfortunately,
   until that approach completes standardization effort we cannot
   recomend its use for ForCES TML.  Higher Priority, Reliable channel

   The higher priority channel uses a standard SCTP reliable socket on
   port 6700.  It is used for CE solicited messages and their responses:

   1.  ForCES configuration messages flowing from CE to FE and responses
       from the FE to CE.

   2.  ForCES query messages flowing from CE to FE and responses from
       the FE to the CE.

   Some events which require guaranteed delivery could also optionally
   use this interface.  An example of an event that would be prioritized
   and delivered on this channel would be a PL heartbeat (in a scenario
   when the first few HBs fail to make it to the destination).  Medium Priority, Mixed Reliable channel

   The medium priority channel uses SCTP-PR on port 6701.  Time limits
   on how long a message is valid are set on each outgoing message.
   This channel is used for events from the FE to the CE that are
   obsoleted over time.  Events that are accumulative in nature and are
   recoverable by the CE (by issuing a query to the FE) can tolerate
   lost events from and therefore should this channel.  Example a counter
   that is monotonically incrementing fits to use this channel.  Lower Priority, Unreliable channel

   The lower priority channel on SCTP associated port 6702 is used for redirect
   messages between the CE and FE.  This channel also uses SCTP-PR with
   lower timeout values than the two streams.

4.3.1. medium priority channel.  The reason an
   unreliable channel is used for redirect messages is to allow the
   control protocol at both the CE and its peer-endpoint to take charge
   of how the end to end semantics of the said control protocol's
   operations.  For example:

   1.  Some control protocols are reliable in nature, therefore making
       this channel reliable introduces an extra layer of reliability
       which could be harmful.  So any end to end retransmits will
       happen from remote.

   2.  Some control protocols may desire to have obsolescence of
       messages over retransmissions; making this channel reliable
       contradicts that desire.  Scheduling of The 3 Channels

   Strict priority work-conserving scheduling is used to process both on
   sending and receving by the TML Core.  This means that the higher
   priority messages are always processed first until there are no more
   left.  The lower priority channel is processed only if a channel that
   is higher priority than itself has no more messages left to process.
   This means that under congestion situation, a higher priority channel
   with sufficient messages that occupy the available bandwidth would
   starve lower priority channel(s).  The authors feel this is justified
   given the choice of the messaging prioritization as described above.  TML Parameterization

   TBA: This section will have a list of all parameters needed for
   booting the TML.  TML Bootstrapping

   TBA: This section will show how the FE and CE side of bootstrapping.

4.2.2.  Satisfying Reliability Requirement

   As mentioned earlier, a shade of reliability ranges is possible in
   SCTP.  Therefore this requirement is met.

   Redirected control traffic in ForCES is not expected to be reliably
   delivered but MUST at the same time be congestion aware.  This
   requirement is also met by SCTP.


4.2.3.  Satisfying Congestion control Control Requirement

   Congestion control is built into SCTP.  Therefore, this requirement
   is met.


4.2.4.  Satisfying Timeliness and prioritization prioritizationi Requirement

   By using multiple streams 3 sockects in conjunction with the partial-reliability
   feature, both timeliness and prioritization can be achieved.


4.2.5.  Satisfying Addressing Requirement

   SCTP can be told to replicast packets to multiple destinations.  The
   TML will translate PL level addresses, to a variety of unicast IP
   addresses in order to emulate multicast and broadcast.  Note,
   however, unlike other proposed TMLs, that
   there are no extra headers required for SCTP.


4.2.6.  Satisfying HA Requirement

   Transport link resiliency is SCTP's strongest point (where it totally
   outclasses all other TML proposals).  Failure detection and recovery
   is built in as mentioned earlier.

   o  The SCTP multi-homing feature is used to provide path diversity.
      Should one of the peer IP addresses become unreachable, the
      other(s) are used without needing lower layer convergence
      (routing, for example) or even the TML becoming aware.

   o  SCTP heartbeats and data transmission thresholds are used on a per
      peer IP address to detect reachability faults.  The faults could
      be a result of an unreachable address or peer, which may be caused
      by a variety of reasons, like interface, network, or endpoint
      failures.  The cause of the fault is noted.

   o  With the ADDIP feature, one can migrate IP addresses to other
      nodes at runtime.  This is not unlike the VRRP[RFC3768] protocol
      use.  This feature is used in addition to multi-homing in a
      planned migration of activity from one FE/CE to another.  In such
      a case, part of the provisioning recipe at the CE for replacing an
      FE involves migrating activity of one FE to another.


4.2.7.  Satisfying DOS prevention

   Two Prevention Requirement

   Three separate streams (one per socket) are used within any FE-CE setup: the higher
   priority one is for configuration and the lower priority one for data
   setup.  The scheduling design is for processing channels
   (Section strict priority to further guarantee priority.  This guarantees that lower
   priority is messages are starved if lack of resources happen.

4.3.7. i.e under
   congestion (which is likely to occur under DOS attack), redirected
   packets (from outside the NE) get very low priority and obsoleted in
   short periods if the CE-FE path is congested without consuming
   resources on the CE-FE path.

4.2.8.  Satisfying Encapsulation Requirement

   There is no extra encapsulation added by this TML.  SCTP provides for
   extensions to be added to it by defining new chunks.  In the future,
   should the need arise, a new SCTP extension can be defined to meet
   newer ForCES requirements.

5.  IANA Considerations

   This document makes no request of IANA.

   Note IANA to RFC Editor: this section may be removed on publication as an
   RFC. reserve SCTP ports 6700, 6701,
   and 6702.

6.  Security Considerations

   TBA: how

   When operating under a secured environment then the network
   administrator can turn off all the security functions.  This feature
   is configured during the pre-association phase of the protocol.  This
   mode is called "no security" mode of operation.

   When the CEs, FEs are running over IP networks or in an insecure
   environment, the operator has the choice of configuring either TLS
   [RFC2246] or IPSec [RFC2401] to provide needed security.  For IPSec,
   The security association between the CEs and FEs MUST be established
   before any ForCES protocol messages are exchanged between the CEs and

6.1.  TLS Usage for Securing TML

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

   Since CE is master and FEs are slaves, the FEs are TLS clients and
   CEs are TLS server.  The endpoints that implement TLS MUST perform
   mutual authentication during TLS session establishment process.  CE
   must request certificate from FE and FE needs to pass the requested

   We recommend TLS-RSA-with-AES-128-CBC-SHA cipher suite.  Although
   consistency is expected it is possible for the CE or FE to negotiate
   other TLS cipher suites.

6.2.  IPSec Usage for securing TML

   This section is applicable for CE or FE endpoints that use TLS,IPSEC the TML
   with IPSec [RFC2401] to secure their respective communication.  IPSec
   is transparent to the higher-layer applications and can provide
   security for any transport layer protocol.  This mechanism is can be
   used to secure just the control or both the control and the data
   channel simultaneously.

   Editorial Note: We need to flesh the security section with more

7.  Manageability Considerations


8.  Acknowledgements

   The authors would like to thank Joel Halpern, Michael Tuxen and Randy
   Stewart for engaging us in discussions that have made this draft

9.  References

9.1.  Normative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

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

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

9.2.  Informative References

              Halpern, J. and E. J., Deleganes, E., and J. Hadi Salim, "ForCES
              Forwarding Element Model", Oct. 2007. February 2008.

              Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J.,
              Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R.
              Gopal, "ForCES Protocol Specification", July 2007. March 2008.

   [TML-API]  M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES
              Transport Mapping Layer (TML) Service Primitives",
              Feb. 2007.

Authors' Addresses

   Jamal Hadi Salim
   ZNYX Networks
   Ottawa, Ontario


   Kentaro Ogawa
   NTT Network Service Systems Laboratories Corporation
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585


Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).