Network Working Group                                      J. Hadi Salim
Internet-Draft                                             ZNYX                                         Mojatatu Networks
Expires: January 15, August 2, 2009                                         K. Ogawa
                                                         NTT Corporation
                                                           July 14, 2008
                                                        January 29, 2009

      SCTP based TML (Transport Mapping Layer) for ForCES protocol
                      draft-ietf-forces-sctptml-01
                      draft-ietf-forces-sctptml-02

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

   This Internet-Draft is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the
   provisions of BCP 78 and 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.

   This Internet-Draft will expire on January 15, August 2, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Abstract

   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  4
     3.2.  The TML layer  . . . . . . . . . . . . . . . . . . . . . .  5
       3.2.1.  TML Parameterization . . .  5
       3.2.1.  TML and PL Interfaces  . . . . . . . . . . . . . .  6
     3.3.  The TML-PL interface . .  5
       3.2.2.  TML Parameterization . . . . . . . . . . . . . . . . .  6
   4.  SCTP TML overview  . . . . . . . . . . . . . . . . . . . . . .  7  6
     4.1.  Rationale for using SCTP for TML . . . . . . . . . . . . .  9  8
     4.2.  Meeting TML requirements . . . . . . . . . . . . . . . . . 10  9
       4.2.1.  SCTP TML Channels  . . . . . . . . . . . . . . . . . . 11 10
       4.2.2.  Satisfying Reliability Requirement TML Requirements  . . . . . . . . . . 13
       4.2.3.  Satisfying Congestion Control Requirement . . . 14
   5.  Channel work scheduling  . . . 13
       4.2.4.  Satisfying Timeliness and prioritizationi
               Requirement . . . . . . . . . . . . . . . . 15
     5.1.  FE Channel work scheduling . . . . . 13
       4.2.5.  Satisfying Addressing Requirement . . . . . . . . . . 14
       4.2.6.  Satisfying HA Requirement . 16
     5.2.  CE Channel work scheduling . . . . . . . . . . . . . 14
       4.2.7.  Satisfying DOS Prevention Requirement . . . 17
   6.  Service Interface  . . . . . . 14
       4.2.8.  Satisfying Encapsulation Requirement . . . . . . . . . 14
   5.  IANA Considerations . . . . . . . 17
     6.1.  TML Boot-strapping . . . . . . . . . . . . . . . 15
   6.  Security Considerations . . . . . 18
     6.2.  TML Shutdown . . . . . . . . . . . . . . 15
     6.1.  TLS Usage for Securing . . . . . . . . . 19
     6.3.  TML Sending and Receiving  . . . . . . . . . . . . . . . . 15
     6.2.  IPSec Usage for securing TML 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . 15
   7.  Manageability . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . 22
     8.1.  TML Security Services using TLS and DTLS . . . . . . . . . 22
       8.1.1.  TLS Usage  . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . 22
     8.2.  TML Security Services using IPsec  . . . . . . . . . . . . 23
       8.2.1.  IPsec Usage  . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . 23
   9.  Manageability Considerations . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . 23
   10. Acknowledgements . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . 24
   11. References . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 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 . . . . . . . . . . . . 24
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
     11.2. Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

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, SCTP, IP, ATM, Ethernet,
   etc), and how to achieve and implement reliability, multicast,
   ordering, security, etc.

2.  Introduction

   The ForCES (Forwarding and Control Element Separation) working group
   in the IETF is defining defines the architecture and protocol for separation of
   Control Elements(CE) and Forwarding Elements(FE) in 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 (Section 3) in order to provide clarity basic
   context to the reader of this document.

   The ForCES layout protocol layering 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          |
                         encapsulation|
                         and          |
                         transport    |
                                      |
                                      v
               +-----------------------------------------------+
               |                   FE TML                      |
               +-----------------------------------------------+
               |                   FE PL                       |
               +-----------------------------------------------+

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

   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 end-points 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 nodes (CE and FE) is expected to be of the same
   definition in order to inter-operate.

   When transmitting, transmitting from a ForCES end-point, 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. TML(s).

   On reception of a message, the TML delivers the message to its
   destination PL layer(s) level (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 level is responsible for associating
   an FE or CE to an NE.  It is also responsible for tearing down such
   associations.

   An FE uses may use the PL layer level to throw various subscribed-to
   events asynchronously send packets to the CE CE.
   The FE may redirect via the PL layer as well as respond (from outside the NE) various control
   protocol packets (e.g.  OSPF, etc) to the CE.  Additionally, the FE
   delivers various events that CE has subscribed-to via PL [FE-MODEL].

   The CE and FE may interact synchronously via the PL.  The CE issues
   status requests issued from to the FE and receives responses via the CE PL.  The CE
   also configures both the FE and associated LFBs attributes FE's LFBs' components 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
   etc.
   [FE-MODEL].

3.2.  The TML layer

   The TML layer level is responsible for transport of the PL layer level messages.
   The TML provides
   [FE-PROTO] section 5 defines the following services on behalf of the ForCES
   protocol:

   1.  Reliability
       As defined requirements that need to be met by RFC 3654, section 6 #6.

   2.  Security
   a TML provides security services to the ForCES PL. specification.  The SCTP TML
       definition needs to define specified in this document meets
   all the requirements specified in [FE-PROTO] section 5.
   Section 4.2.2 describes how the following TML requirements are achieved:

       *  Endpoint authentication of FE and CE

       *  Message authentication

       *  Confidentiality service

   3.  Congestion Control
       The congestion control mechanism defined by the met.

3.2.1.  TML should
       prevent the FE from being overloaded by the CE.  Additionally,
       the circumstances under which notification is sent and PL Interfaces

   There are two interfaces to the PL to
       notify it and TML, both of congestion must be defined.

   4.  Uni/multi/broadcast addressing/delivery, if any
       If there which are out of
   scope for ForCES.  The first one is any mapping the interface between the 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 and the other is the TML's
       responsibility.  However, on config basis, CE Manager (CEM)/FE Manager (FEM)[RFC3746]
   interface to both the PL layer may wish
       to participate and TML.  Both interfaces are shown in link failover schemes
   Figure 2.

   [TML-API] defines an interface between the PL 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. layers.
   The TML needs end goal of [TML-API] is to specify the
       encapsulation used.

   7.  Prioritization
       The TML SHOULD will be able provide a consistent top edge
   semantics for all TMLs to handle up adhere to.  Conforming to 8 priority levels
       needed by the PL and will provide preferential treatment.
       The TML needs such an interface
   makes it easy to define how this is achieved.

   8.  Protection against DoS attacks
       As described plug 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 over time for a singular PL.

                      +----------------------------+
                      |  +----------------------+  |
                      |  |                      |  |
     +---------+      |  |       PL Layer       |  |
     |         |      |  +----------------------+  |
     |FEM/CEM  |<---->|             ^              |
     |         |      |             |              |
     +---------+      |             |TML API       |
                      |             |              |
                      |             V              |
                      |  +----------------------+  |
                      |  |                      |  |
                      |  |       TML Layer      |  |
                      |  |                      |  |
                      |  +----------------------+  |
                      +----------------------------+

                      Figure 2: The TML-PL interface
   XXX - Editorial Note: There is
   standardized, interoperability some concern (and confusion) about
   defining APIs in ForCES.  So at the moment the future of [TML-API] is guaranteed only as long
   unknown and we will remove references to it in future revisions of
   this document.

   Figure 2 also shows an interface referred to as both
   endpoints support CEM/FEM[RFC3746]
   which is responsible for bootstrapping and parameterization of the same
   TML.

3.2.1.  In its most basic form the CEM/FEM interface takes the form of
   a simple static config file which is read on startup in the pre-
   association phase.

   Section 6 discusses in more details the service interfaces.

3.2.2.  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
      IP/SCTP then parameters such as TCP and UDP SCTP 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
      Policy)

3.3.  The TML-PL interface

   [TML-API] defines an interface between the PL and the

4.  SCTP TML layers.
   The end goal of [TML-API] overview

   SCTP [RFC2960] is to provide a consistent top edge
   semantics for all TMLs to adhere to.  Conforming to such an interface
   makes it easy end-to-end transport protocol that is equivalent
   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
                             |
                             |
                             V
                  +----------------------+
                  |                      |
                  |       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
   background.

   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

   SCTP [RFC2960] is an end-to-end transport protocol that is equivalent
   to TCP, UDP, or DCCP 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 Dynamic Address Reconfiguration ([RFC5061]) feature,
      a new IP 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 up to 64K
      independent streams over the same socket connection, which are
      ordered independently.

   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 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 that can be
      subscribed-to include indication of association changes,
      addressing changes, remote errors, expiry of timed messages, 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 crosses different memory
      domains within a host. host (example in a kernel to user space domain of
      an operating system).

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 protocols in order to satisfy the
   other proposals for TMLs. TML requirements
   ([FE-PROTO] section 5).  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 used making it a superior good choice in comparison with other proposed
   TMLs. for
   ubiquitous deployment.

4.2.  Meeting TML requirements

                  PL
                  +---------------------+
                  +----------------------+
                  |                      |
                  +-----------+---------+
                  +-----------+----------+
                              |   TML API
                   TML        |
                  +-----------+----------+
                  |           |          |
                  |    +------+------+   |
                  |    |  TML core   |   |
                  |    +-+----+----+-+   |
                  |      |    |    |     |
                  |    SCTP socket API   |
                  |      |    |    |     |
                  |      |    |    |     |
                  |    +-+----+----+-+   |
                  |    |    SCTP     |   |
                  |    +------+------+   |
                  |           |          |
                  |           |          |
                  |    +------+------+   |
                  |    |      IP     |   |
                  |    +-------------+   |
                  +----------------------+

                     Figure 3: The TML-SCTP interface

   Figure 3 details the interfacing between the TML PL and SCTP TML and the
   internals of the SCTP TML.  The core of the TML interfaces interacts on its
   north bound
   north-bound interface to the PL (utilizing the TML API).  On the
   southbound
   south-bound interface, the TML core interfaces to the SCTP layer
   utilizing the standard socket interface [Editorial: [XXX Editorial: add here a
   reference to SCTP Sockets API doc].  There are three SCTP socket
   connections opened between any two PL layers endpoints (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.

4.2.1.1.  Justifying Choice of 3 Sockets

   SCTP allows upto up to 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
   ports.

   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  For this reason, we elected to
   go with mapping each of the medium and low priority three 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 a different SCTP to prioritize streams socket
   (instead of a different stream within a single socket.  Unfortunately,
   until that approach completes standardization effort we cannot
   recomend its use for ForCES TML. socket).

4.2.1.2.  Higher Priority, Reliable channel

   The higher priority (HP) 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

   It is recommended 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 following PL messages use the destination). HP channel
   for transport:

   o  Association Setup

   o  Association Setup Response

   o  Association Teardown

   o  Config

   o  Config Response

   o  Query

   o  Query Response

4.2.1.3.  Medium Priority, Mixed Reliable Semi-Reliable channel

   The medium priority (MP) 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 and therefore should use this channel.  Example  For example, a
   generated event which carries the value of a counter that is
   monotonically incrementing fits to use this channel.

   It is recommended that the following PL messages use the MP channel
   for transport:

   o  Event Notification

4.2.1.4.  Lower Priority, Unreliable channel

   The lower priority (LP) channel on uses SCTP port 6702 is used for redirect
   messages between the CE and FE. 6702.  This channel
   also uses SCTP-PR with lower timeout values than the medium priority MP 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 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 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.

4.2.1.5.  Scheduling of

   Given ForCES PL level heartbeats are traffic sensitive, sending them
   over the LP channel also makes sense.  If the other end is not
   processing other channels it will eventually get heartbeats; and if
   it is busy processing other channels heartbeats will be obsoleted
   locally over time (and it does not matter if they did not make it).

   It is recommended that the following PL messages use the MP channel
   for transport:

   o  Packet Redirect

   o  Heartbeats

4.2.1.5.  Scheduling of The 3 Channels

   Strict priority work-conserving scheduling is used to process both on
   sending and receving receiving (of the PL messages) by the TML Core. Core as shown
   in Figure 5.

   This means that the higher
   priority HP messages are always processed first until
   there are no more left.  The lower priority LP 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 design intent of the messaging SCTP TML is to tie prioritization as
   described above. in Section 4.2.1.1 and transport congestion control to
   provide implicit node congestion control.  This is further detailed
   in Section 5.

       SCTP channel            +----------+
       Work available          |   DONE   +---<--<--+
           |                   +---+------+         |
           Y                                        ^
           |         +-->--+         +-->---+       |
   +-->-->-+         |     |         |      |       |
   |       |         |     |         |      |       ^
   |       ^         ^     Y         ^      Y       |
   ^      / \        |     |         |      |       |
   |     /   \       |     ^         |      ^       ^
   |    / Is  \      |    / \        |     / \      |
   |   / there \     |   /Is \       |    /Is \     |
   ^  / HP work \    ^  /there\      ^   /there\    ^
   |  \    ?    /    | /MP work\     |  /LP work\   |
   |   \       /     | \    ?  /     |  \   ?   /   |
   |    \     /      |  \     /      |   \     /    ^
   |     \   /       ^   \   /       ^    \   /     |
   |      \ /        |    \ /        |     \ /      |
   ^       Y-->-->-->+     Y-->-->-->+      Y->->->-+
   |       |    NO         |    NO          |  NO
   |       |               |                |
   |       Y               Y                Y
   |       | YES           | YES            |
   ^       |               |                |
   |       Y               Y                Y
   |  +----+------+    +---|-------+   +----|------+
   |  |- process  |    |- process  |   |- process  |
   |  |  HP work  |    |  MP work  |   | LP work   |
   |  +------+----+    +-----+-----+   +-----+-----+
   |         |               |               |
   ^         Y               Y               Y
   |         |               |               |
   |         Y               Y               Y
   +--<--<---+--<--<----<----+-----<---<-----+

               Figure 5: SCTP TML Strict Priority Scheduling

4.2.1.6.  SCTP TML Parameterization

   TBA: This section will have

   The following is a list of all parameters needed for booting the TML.

4.2.1.7.  TML Bootstrapping

   TBA: This section  It
   is expected these parameters will show how be extracted via the FE and CE side FEM/CEM
   interface for each PL ID.

   1.  The IP address or a resolvable DNS/hostname of bootstrapping. the CE/FE.

   2.  The HP SCTP port, as discussed in Section 4.2.1.2.  The default
       HP port value is 6700 (Section 7).

   3.  The MP SCTP port, as discussed in Section 4.2.1.3. default MP
       port value is 6701 (Section 7).

   4.  The LP SCTP port, as discussed in Section 4.2.1.4. default LP
       port value is 6702 (Section 7).

4.2.2.  Satisfying TML Requirements

   [FE-PROTO] section 5 lists requirements that a TML needs to meet.
   This section describes how the SCTP TML satisfies those requirements.

4.2.2.1.  Satisfying Reliability Requirement

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

4.2.3.

4.2.2.2.  Satisfying Congestion Control Requirement

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

4.2.4.

4.2.2.3.  Satisfying Timeliness and prioritizationi Prioritization Requirement

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

4.2.5.

4.2.2.4.  Satisfying Addressing Requirement

   There are no extra headers required for SCTP to fulfil this
   requirement.  SCTP can be told to replicast packets to multiple
   destinations.  The TML implementation will need to translate PL level
   addresses, to a variety of unicast IP addresses in order to emulate
   multicast and broadcast.  Note, that
   there are no extra headers required for SCTP.

4.2.6. broadcast PL addresses.

4.2.2.5.  Satisfying HA Requirement

   Transport link resiliency is one of SCTP's strongest point (where it totally
   outclasses all other TML proposals). point.  Failure
   detection and recovery is built in 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.

4.2.2.6.  Satisfying DOS Prevention Requirement

   Three separate streams (one channels, one per socket) socket, are used within any FE-CE
   setup.  The scheduling design for processing channels
   (Section 4.2.1.5)is 4.2.1.5) is strict priority.  This guarantees that lower priority messages are starved if lack and ties transport and node
   overload implicitly together.  The HP channel work gets prioritized
   at the expense of resources happen. i.e under
   congestion (which is likely to occur under DOS attack), the MP and LP channels in the presence of low
   processing and bandwidth resource conditions.  I.e., if redirected
   packets (from outside the NE) attempt to overload the NE, they get
   assigned very low priority and obsoleted in
   short periods if obsoleted in short periods if either
   the CE or FE is busy processing more important work or the CE-FE path
   is congested.  Refer to Section 5 for details.

4.2.2.7.  Satisfying Encapsulation Requirement

   There is no extra encapsulation added by the SCTP TML.

   In the future, should the need arise, a new SCTP extension/chunk can
   be defined to meet newer ForCES requirements [XXX: Editorial note:
   provide reference to SCTP extensibility].

5.  Channel work scheduling

   This section provides high level details of the scheduling view of
   the SCTP TML core (Section 4.2.1).  A practical scheduler
   implementation takes care of many little details (such as timers,
   work quanta, etc) not described in this document.  The implementor is
   left to take care of those details.

   The CE(s) and FE(s) are coupled together in the principles of the
   scheduling scheme described here to tie together node overload with
   transport congestion.  The design intent is to provide the highest
   possible robust work throughput for the NE under any network or
   processing congestion.

   XXX (Editorial note): We need to solicit feedback whether it would
   help implementors if we publish algorithm for the CE/FE scheduling in
   the form of pseudo-code.

5.1.  FE Channel work scheduling

   The FE scheduling, in priority order, needs to I/O process:

   1.  The HP channel I/O in the following priority order:

       1.  Transmitting back to the CE any outstanding result of
           executed work via the HP channel transmit path.

       2.  Taking new incoming work from the CE which creates ForCES
           work to be executed by the FE.

   2.  ForCES events which result in transmission of unsolicited ForCES
       packets to the CE via the MP channel.

   3.  Incoming Redirect work in the form of control packets that come
       from the CE via LP channel.  After redirect processing, these
       packets get sent out on external (to the NE) interface.

   4.  Incoming Redirect work in the form of control packets that come
       from other NEs via external (to the NE) interfaces.  After some
       processing, such packets are sent to the CE.

   It is worth emphasizing at this point again that the SCTP TML
   processes the channel work in strict priority.  For example, as long
   as there are messages to send to the CE on the HP channel, they will
   be processed first until there are no more left before processing the
   next priority work (which is to read new messages on the HP channel
   incoming from the CE).

5.2.  CE Channel work scheduling

   The CE scheduling, in priority order, needs to deal with:

   1.  The HP channel I/O in the following priority order:

       1.  Process incoming responses to requests of work it made to the
           FE(s).

       2.  Transmitting any outstanding HP work it needs for the FE(s)
           to complete.

   2.  Incoming ForCES events from the FE(s) via the MP channel.

   3.  Outgoing Redirect work in the form of control packets that get
       sent from the CE via LP channel destined to external (to the NE)
       interface on FE(s).

   4.  Incoming Redirect work in the form of control packets that come
       from other NEs via external (to the NE) interfaces on the FE(s).

   It is worth to repeat for emphasis again that the SCTP TML processes
   the channel work in strict priority.  For example, if there are
   messages incoming from an FE on the HP channel, they will be
   processed first until there are no more left before processing the
   next priority work which is to transmit any outstanding HP channel
   messages going to the FE.

6.  Service Interface

   XXX - Editorial Note and repeated emphasis: There is some concern
   (and confusion) about defining APIs in ForCES.  So at the moment the
   future of [TML-API] is unknown and we will remove references to it in
   future revisions of this document.

   This section provides high level service interface between FEM/CEM
   and TML, the PL and TML, and between local and remote TMLs.  The
   intent of this interface discussion is to provide general guidelines.
   The implementer is expected to worry about details and even follow a
   different approach if needed.

   The theory of operation for the PL-TML service is as follows:

   1.  The PL starts up and bootstraps the TML.  The end result of a
       successful TML bootstrap is that the CE TML and the FE TML
       connect to each other at the transport level.

   2.  Sending and reception of the PL level messages commences after a
       successful TML bootstrap.  The PL uses send and receive PL-TML
       interfaces to communicate to its peers.  The TML is agnostic to
       the nature of the messages being sent or received.  The first
       message exchanges that happen are to establish ForCES
       association.  Subsequent messages maybe either unsolicited events
       from the FE PL, control message redirects from/to the CE to/from
       FE, and configuration from the CE to the FE and their responses
       flowing from the FE to the CE.

   3.  The PL does a shutdown of the TML after terminating ForCES
       association.

6.1.  TML Boot-strapping

   Figure 6 illustrates a flow for the TML bootstrapped by the PL.

   When the PL starts up (possibly after some internal initialization),
   it boots up the TML.  The TML first interacts with the FEM/CEM and
   acquires the necessary TML parameterization (Section 4.2.1.6).  Next
   the TML uses the information it retrieved from the FEM/CEM interface
   to initialize itself.

   The TML on the FE proceeds to connect the 3 channels to the CE.  The
   socket interface is used for each of the channels.  The TML continues
   to re-try the connections to the CE until all 3 channels are
   connected.  It is advisable that the number of connection retry
   attempts and the time between each retry is also configurable via the
   FEM.  On failure to connect one or more channels, and after the
   configured number of retry thresholds is exceeded, the TML will
   return an appropriate failure indicator to the PL.  On success (as
   shown in Figure 6), a success indication is presented to the TML.

   FE PL      FE TML           FEM  CEM        CE TML              CE PL
     |            |             |    |            |                    |
     |            |             |    |            |      Bootup        |
     |            |             |    |            |<-------------------|
     |  Bootup    |             |    |            |                    |
     |----------->|             |    |get CEM info|                    |
     |            |get FEM info |    |<-----------|                    |
     |            |------------>|    ~            ~                    |
     |            ~             ~    |----------->|                    |
     |            |<------------|                 |                    |
     |            |                               |-initialize TML     |
     |            |                               |-create the 3 chans.|
     |            |                               | to listen to FEs   |
     |            |                               |                    |
     |            |-initialize TML                |Bootup success      |
     |            |-create the 3 chans. locally   |------------------->|
     |            |-connect 3 chans. remotely     |                    |
     |            |------------------------------>|                    |
     |            ~                               ~ - FE TML connected ~
     |            ~                               ~ - FE TML info init ~
     |            | channels connected            |                    |
     |            |<------------------------------|                    |
     | Bootup     |                               |                    |
     | succeeded  |                               |                    |
     |<-----------|                               |                    |
     |            |                               |                    |

                     Figure 6: SCTP TML Bootstrapping

   On the CE things are slightly different.  After initializing from the
   CEM, the TML on the CE side proceeds to initialize the 3 channels to
   listen to remote connections from the FEs.  The success or failure
   indication is passed on to the CE PL level (in the same manner as was
   done in the FE).

   Post boot-up, the CE TML waits for connections from the FEs.  Upon a
   successful connection by an FE, the CE TML level keeps track of the
   transport level details of the FE.  Note, at this stage only
   transport level connection has been established; ForCES level
   association follows using send/receive PL-TML interfaces (refer to
   Section 6.3 and Figure 8).

6.2.  TML Shutdown

   Figure 7 shows an example of an FE shutting down the TML.  It is
   assumed at this point that the ForCES Association Teardown has been
   issued by the CE.

   When the FE PL issues a shutdown to its TML for a specific PL ID, the
   TML releases all the channel connections to the CE.  This is achieved
   by closing the sockets used to communicate to the CE.

   FE PL      FE TML                      CE TML              CE PL
     |            |                         |                    |
     |  Shutdown  |                         |                    |
     |----------->|                         |                    |
     |            |-disconnect 3 chans.     |                    |
     |            |------------------------>|                    |
     |            |                         |                    |
     |            |                         |-FE TML info cleanup|
     |            |                         |-optionally tell PL |
     |            |                         |------------------->|
     |            |- clean up any state of  |                    |
     |            | channels disconnected   |                    |
     |            |                         |                    |
     |            |<------------------------|                    |
     | Shutdown   |                         |                    |
     | succeeded  |                         |                    |
     |<-----------|                         |                    |
     |            |                         |                    |

                        Figure 7: FE Shutting down

   On the CE side, a TML level disconnection would result in possible
   cleanup of the FE state.  Optionally, depending on the
   implementation, there may be need to inform the PL about the TML
   disconnection.

6.3.  TML Sending and Receiving

   The TML is agnostic to the nature of the PL message it delivers to
   the remote TML (which subsequently delivers the message to its PL).
   Figure 8 shows an example of a message exchange originated at the FE
   and sent to the CE (such as a ForCES association message) which
   illustrates all the necessary service interfaces for sending and
   receiving.

   When the FE PL sends a message to the TML, the TML is expected to
   pick one of HP/MP/LP channels and send out the ForCES message.

   FE PL       FE TML           CE TML                CE PL
      |            |              |                      |
      |PL send     |              |                      |
      |----------->|              |                      |
      |            |              |                      |
      |            |-Format msg.  |                      |
      |            |-pick channel |                      |
      |            |-TML  Send    |                      |
      |            |------------->|                      |
      |            |              |-TML Receive on chan. |
      |            |              |-decapsulate          |
      |            |              |- mux to PL/PL recv   |
      |            |              |--------------------->|
      |            |              |                      ~
      |            |              |                      ~ PL Process
      |            |              |                      ~
      |            |              |  PL send             |
      |            |              |<---------------------|
      |            |              |-Format msg. for send |
      |            |              |-pick chan to send on |
      |            |              |-TML send             |
      |            |<-------------|                      |
      |            |-TML Receive  |                      |
      |            |-decapsulate  |                      |
      |            |-mux to PL    |                      |
      | PL Recv    |              |                      |
      |<---------- |              |                      |
      |            |              |                      |

                       Figure 8: Send and Recv Flow

   When the CE-FE path is congested without consuming
   resources CE TML receives the ForCES message on the CE-FE path.

4.2.8.  Satisfying Encapsulation Requirement

   There is no extra encapsulation added by this TML.  SCTP provides for
   extensions channel it was
   sent on, it demultiplexes the message to be added the CE PL.

   The CE PL, after some processing (in this example dealing with the
   FE's association), sends to it by defining new chunks.  In the future,
   should TML the need arise, a new SCTP extension can be defined response.  And as in the case
   of FE PL, the CE TML picks the channel to meet
   newer send on before sending.

   The processing of the ForCES requirements.

5. message upon arriving at the FE TML and
   delivery to the FE PL is similar to the CE side equivalent as shown
   above in Section 6.3.

7.  IANA Considerations

   This document makes request of IANA to reserve SCTP ports 6700, 6701,
   and 6702.

6.

8.  Security Considerations

   When operating under

   The SCTP TML provides the following security services to the PL
   level:

   o  A mechanism to authenticate ForCES CEs and FEs at transport level
      in order to prevent the participation of unauthorized CEs and
      unauthorized FEs in the control and data path processing of a secured environment then
      ForCES NE.

   o  A mechanism to ensure message authentication of PL data and
      headers transferred from the network
   administrator can turn off all CE to FE (and vice-versa) in order to
      prevent the security functions.  This feature
   is configured injection of incorrect data into PL messages.

   o  A mechanism to ensure the confidentiality of PL data and headers
      transferred from the CE to FE (and vice-versa), in order to
      prevent disclosure of PL level information transported via the
      TML.

   Security choices provided by the TML are made by the operator and
   take effect during the pre-association phase of the ForCES protocol.  This
   mode is called "no security" mode
   An operator may choose to use all, some or none of operation.

   When the CEs, FEs are running over IP networks or security
   services provided by the TML in an insecure a CE-FE connection.

   When operating under a secured environment, or for other operational
   concerns (in some cases performance issues) the operator may turn off
   all the security functions between CE and FE.

   The operator has the choice of configuring either TLS
   [RFC2246] a combination of
   Transport Layer Security(TLS) [RFC4346] and Datagram Transport Layer
   Security(DTLS) [RFC4347], or IPSec [RFC2401] IP Security Protocol (IPsec) [RFC4301]
   to provide needed security.  For IPSec,
   The security association between  It is recommended that the CEs TLS/DTLS
   combination is used and FEs MUST only in its absence should IPsec be established
   before any ForCES protocol messages are exchanged between the CEs
   considered.

   XXXX: Editors note: we should take note of RFC 3554 and
   FEs.

6.1.  TLS Usage for Securing 3436

8.1.  TML

   This section is applicable for CE or FE endpoints that use Security Services using TLS and DTLS

   TLS and DTLS were designed to provide the mutual authentication,
   message integrity and message confidentiality outlined in the TML
   with
   security requirements ([FE-PROTO]).

8.1.1.  TLS [RFC2246] to secure communication. Usage

   Since in the ForCES architecture, the CE is master and FEs are
   slaves, the FEs are TLS D/TLS clients and CEs are TLS D/TLS server.  The FE
   HP channel opens a TLS connection on SCTP port 6700.  The FE MP and
   LP channels open DTLS connections on SCTP ports 6701 and 6702
   respectively.

   The endpoints that implement TLS D/TLS MUST perform mutual authentication
   during TLS D/TLS session establishment process.  CE
   must request certificate from FE and FE needs  Certificates are used to pass the requested
   information.
   achieve mutual authentication.

   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 D/TLS cipher suites.

6.2.  IPSec Usage for securing TML

   This section is applicable for CE or FE endpoints that use the

8.2.  TML
   with IPSec [RFC2401] Security Services using IPsec

   XXXX: Editors note: We should review what RFCs to secure their respective communication.  IPSec list as references
   (eg IKEv2, ESP etc).

   IPsec is an IP level security scheme transparent to the higher-layer
   applications and therefore can provide security for any transport
   layer protocol.  This mechanism is gives IPsec the advantage that it can be used
   to secure just the control or both everything between the control CE and FE without expecting the data
   channel simultaneously.

   Editorial Note: We need TML
   implementation to be aware of the details.

   The IPsec architecture is designed to flesh provide message integrity and
   message confidentiality outlined in the TML security section requirements
   ([FE-PROTO]).  Mutual authentication and key exchange protocol
   Internet Key Exchange (IKE)[RFC4109].

8.2.1.  IPsec Usage

   It is recommended that the following options be used for consistency
   (although it is expected to be possible for the CE or FE to negotiate
   other cipher suites):

   o  Internet Key Exchange (IKE)[RFC4109] with certificates for
      endpoint authentication.

   o  Transport Mode Encapsulating Security Payload (ESP)

   o  HMAC-SHA1-96 [RFC2404] for message integrity protection

   o  AES-CBC with more
   details.

7. 128-bit keys [RFC3602] for message confidentiality.

9.  Manageability Considerations

   TBA

8.

10.  Acknowledgements

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

9.

11.  References

9.1.

11.1.  Normative References

   [RFC2246]  Dierks, T. and

   [RFC2404]  Madson, C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2401, 2404, 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.

   [RFC3602]  Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
              Algorithm and Its Use with IPsec", RFC 3602,
              September 2003.

   [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.

   [RFC4109]  Hoffman, P., "Algorithms for Internet Key Exchange version
              1 (IKEv1)", RFC 4109, May 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061,
              September 2007.

11.2.  Informative References

   [FE-MODEL]
              Halpern, J., Deleganes, E., J. and J. Hadi Salim, "ForCES Forwarding Element
              Model", February October 2008.

   [FE-PROTO]
              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", March November 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
   Mojatatu Networks
   Ottawa, Ontario
   Canada

   Email: hadi@znyx.com hadi@mojatatu.com

   Kentaro Ogawa
   NTT Corporation
   3-9-11 Midori-cho
   Musashino-shi, Tokyo  180-8585
   Japan

   Email: ogawa.kentaro@lab.ntt.co.jp

Full Copyright Statement

   Copyright (C) The IETF Trust (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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET 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.

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