draft-ietf-forces-sctptml-01.txt   draft-ietf-forces-sctptml-02.txt 
Network Working Group J. Hadi Salim Network Working Group J. Hadi Salim
Internet-Draft ZNYX Networks Internet-Draft Mojatatu Networks
Expires: January 15, 2009 K. Ogawa Expires: August 2, 2009 K. Ogawa
NTT Corporation NTT Corporation
July 14, 2008 January 29, 2009
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP based TML (Transport Mapping Layer) for ForCES protocol
draft-ietf-forces-sctptml-01 draft-ietf-forces-sctptml-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009. This Internet-Draft will expire on 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 Abstract
This document defines the SCTP based TML (Transport Mapping Layer) This document defines the SCTP based TML (Transport Mapping Layer)
for the ForCES protocol. It explains the rationale for choosing the for the ForCES protocol. It explains the rationale for choosing the
SCTP (Stream Control Transmission Protocol) [RFC2960] and also SCTP (Stream Control Transmission Protocol) [RFC2960] and also
describes how this TML addresses all the requirements described in describes how this TML addresses all the requirements described in
[RFC3654] and the ForCES protocol [FE-PROTO] draft. [RFC3654] and the ForCES protocol [FE-PROTO] draft.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3
3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The TML layer . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. TML Parameterization . . . . . . . . . . . . . . . . . 6 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5
3.3. The TML-PL interface . . . . . . . . . . . . . . . . . . . 6 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 9 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8
4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 10 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 9
4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 11 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 10
4.2.2. Satisfying Reliability Requirement . . . . . . . . . . 13 4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14
4.2.3. Satisfying Congestion Control Requirement . . . . . . 13 5. Channel work scheduling . . . . . . . . . . . . . . . . . . . 15
4.2.4. Satisfying Timeliness and prioritizationi 5.1. FE Channel work scheduling . . . . . . . . . . . . . . . . 16
Requirement . . . . . . . . . . . . . . . . . . . . . 13 5.2. CE Channel work scheduling . . . . . . . . . . . . . . . . 17
4.2.5. Satisfying Addressing Requirement . . . . . . . . . . 14 6. Service Interface . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. Satisfying HA Requirement . . . . . . . . . . . . . . 14 6.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 18
4.2.7. Satisfying DOS Prevention Requirement . . . . . . . . 14 6.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.8. Satisfying Encapsulation Requirement . . . . . . . . . 14 6.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6.1. TLS Usage for Securing TML . . . . . . . . . . . . . . . . 15 8.1. TML Security Services using TLS and DTLS . . . . . . . . . 22
6.2. IPSec Usage for securing TML . . . . . . . . . . . . . . . 15 8.1.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . 22
7. Manageability Considerations . . . . . . . . . . . . . . . . . 16 8.2. TML Security Services using IPsec . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8.2.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Manageability Considerations . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Definitions 1. Definitions
The following definitions are taken from [RFC3654]and [RFC3746]: The following definitions are taken from [RFC3654]and [RFC3746]:
ForCES Protocol -- The protocol used at the Fp reference point in the ForCES Protocol -- The protocol used at the Fp reference point in the
ForCES Framework in [RFC3746]. ForCES Framework in [RFC3746].
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
architecture that defines the ForCES protocol architecture and the architecture that defines the ForCES protocol architecture and the
state transfer mechanisms as defined in [FE-PROTO]. state transfer mechanisms as defined in [FE-PROTO].
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
ForCES protocol architecture that specifically addresses the protocol ForCES protocol architecture that specifically addresses the protocol
message transportation issues, such as how the protocol messages are message transportation issues, such as how the protocol messages are
mapped to different transport media (like TCP, IP, ATM, Ethernet, mapped to different transport media (like SCTP, IP, ATM, Ethernet,
etc), and how to achieve and implement reliability, multicast, etc), and how to achieve and implement reliability, security, etc.
ordering, etc.
2. Introduction 2. Introduction
The ForCES (Forwarding and Control Element Separation) working group The ForCES (Forwarding and Control Element Separation) working group
in the IETF is defining the architecture and protocol for separation in the IETF defines the architecture and protocol for separation of
of Control Elements(CE) and Forwarding Elements(FE) in Network Control Elements(CE) and Forwarding Elements(FE) in Network
Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively
define architectural and protocol requirements for the communication define architectural and protocol requirements for the communication
between CE and FE. The ForCES protocol layer specification between CE and FE. The ForCES protocol layer specification
[FE-PROTO] describes the protocol semantics and workings. The ForCES [FE-PROTO] describes the protocol semantics and workings. The ForCES
protocol layer operates on top of an inter-connect hiding layer known protocol layer operates on top of an inter-connect hiding layer known
as the TML. The relationship is illustrated in Figure 1. as the TML. The relationship is illustrated in Figure 1.
This document defines the SCTP based TML for the ForCES protocol This document defines the SCTP based TML for the ForCES protocol
layer. It also addresses all the requirements for the TML including layer. It also addresses all the requirements for the TML including
security, reliability, etc as defined in [FE-PROTO]. 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 3. Protocol Framework Overview
The reader is referred to the Framework document [RFC3746], and in The reader is referred to the Framework document [RFC3746], and in
particular sections 3 and 4, for an architectural overview and particular sections 3 and 4, for an architectural overview and
explanation of where and how the ForCES protocol fits in. explanation of where and how the ForCES protocol fits in.
There is some content overlap between the ForCES protocol draft There is some content overlap between the ForCES protocol draft
[FE-PROTO] and this section in order to provide clarity to the reader [FE-PROTO] and this section (Section 3) in order to provide basic
of this document. context to the reader of this document.
The ForCES layout constitutes two pieces: the PL and TML layer. This The ForCES protocol layering constitutes two pieces: the PL and TML
is depicted in Figure 1. layer. This is depicted in Figure 1.
+----------------------------------------------+ +----------------------------------------------+
| CE PL | | CE PL |
+----------------------------------------------+ +----------------------------------------------+
| CE TML | | CE TML |
+----------------------------------------------+ +----------------------------------------------+
^ ^
| |
ForCES | (i.e. Forces data + control ForCES PL | messages
PL | packets )
messages |
over |
specific |
TML |
encapsulation|
and |
transport |
| |
v v
+-----------------------------------------------+ +-----------------------------------------------+
| FE TML | | FE TML |
+-----------------------------------------------+ +-----------------------------------------------+
| FE PL | | FE PL |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 1: Message exchange between CE and FE to establish an NE Figure 1: Message exchange between CE and FE to establish an NE
association association
The PL layer is in charge of the ForCES protocol. Its semantics and The PL is in charge of the ForCES protocol. Its semantics and
message layout are defined in [FE-PROTO]. The TML Layer is necessary message layout are defined in [FE-PROTO]. The TML is necessary to
to connect two ForCES PL layers as shown in Figure 1. connect two ForCES end-points as shown in Figure 1.
Both the PL and TML are standardized by the IETF. While only one PL 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 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 at each of the nodes (CE and FE) is expected to be of the same
definition in order to inter-operate. definition in order to inter-operate.
When transmitting, the PL delivers its messages to the TML. The TML When transmitting from a ForCES end-point, the PL delivers its
then delivers the PL message to the destination peer TML(s) as messages to the TML. The TML then delivers the PL message to the
defined by the addressing in the PL message. destination TML(s).
On reception of a message, the TML delivers the message to its On reception of a message, the TML delivers the message to its
destination PL layer(s) (as described in the ForCES header). destination PL level (as described in the ForCES header).
3.1. The PL 3.1. The PL
The PL is common to all implementations of ForCES and is standardized The PL is common to all implementations of ForCES and is standardized
by the IETF [FE-PROTO]. The PL layer is responsible for associating by the IETF [FE-PROTO]. The PL level is responsible for associating
an FE or CE to an NE. It is also responsible for tearing down such 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 associations.
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
etc.
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
protocol:
1. Reliability
As defined by RFC 3654, section 6 #6.
2. Security An FE may use the PL level to asynchronously send packets to the CE.
TML provides security services to the ForCES PL. The TML The FE may redirect via the PL (from outside the NE) various control
definition needs to define how the following are achieved: protocol packets (e.g. OSPF, etc) to the CE. Additionally, the FE
delivers various events that CE has subscribed-to via PL [FE-MODEL].
* Endpoint authentication of FE and CE The CE and FE may interact synchronously via the PL. The CE issues
status requests to the FE and receives responses via the PL. The CE
also configures the associated FE's LFBs' components using the PL
[FE-MODEL].
* Message authentication 3.2. The TML
* Confidentiality service The TML level is responsible for transport of the PL level messages.
[FE-PROTO] section 5 defines the requirements that need to be met by
a TML specification. The SCTP TML specified in this document meets
all the requirements specified in [FE-PROTO] section 5.
Section 4.2.2 describes how the TML requirements are met.
3. Congestion Control 3.2.1. TML and PL Interfaces
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 There are two interfaces to the PL and TML, both of which are out of
If there is any mapping between PL and TML level uni/multi/ scope for ForCES. The first one is the interface between the PL and
broadcast addressing it needs to be defined. TML and the other is the CE Manager (CEM)/FE Manager (FEM)[RFC3746]
interface to both the PL and TML. Both interfaces are shown in
Figure 2.
5. Transport High Availability [TML-API] defines an interface between the PL and the TML layers.
It is expected that availability of transport links is the TML's The end goal of [TML-API] is to provide a consistent top edge
responsibility. However, on config basis, the PL layer may wish semantics for all TMLs to adhere to. Conforming to such an interface
to participate in link failover schemes and therefore the TML makes it easy to plug in different TMLs over time for a singular PL.
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. +---------+ | | PL Layer | |
| | | +----------------------+ |
|FEM/CEM |<---->| ^ |
| | | | |
+---------+ | |TML API |
| | |
| V |
| +----------------------+ |
| | | |
| | TML Layer | |
| | | |
| +----------------------+ |
+----------------------------+
7. Prioritization Figure 2: The TML-PL interface
The TML SHOULD will be able to handle up to 8 priority levels XXX - Editorial Note: There is some concern (and confusion) about
needed by the PL and will provide preferential treatment. defining APIs in ForCES. So at the moment the future of [TML-API] is
The TML needs to define how this is achieved. unknown and we will remove references to it in future revisions of
this document.
8. Protection against DoS attacks Figure 2 also shows an interface referred to as CEM/FEM[RFC3746]
As described in the Requirements RFC 3654, section 6 which is responsible for bootstrapping and parameterization of the
TML. 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.
It is expected more than one TML will be standardized. The different Section 6 discusses in more details the service interfaces.
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 3.2.2. TML Parameterization
It is expected that it should be possible to use a configuration 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. reference point, such as the FEM or the CEM, to configure the TML.
Some of the configured parameters may include: Some of the configured parameters may include:
o PL ID o PL ID
o Connection Type and associated data. For example if a TML uses 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 IP/SCTP then parameters such as SCTP ports and IP addresses need
addresses need to be configured. to be configured.
o Number of transport connections o Number of transport connections
o Connection Capability, such as bandwidth, etc. o Connection Capability, such as bandwidth, etc.
o Allowed/Supported Connection QoS policy (or Congestion Control o Allowed/Supported Connection QoS policy (or Congestion Control
Policy) Policy)
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
|
|
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 4. SCTP TML overview
SCTP [RFC2960] is an end-to-end transport protocol that is equivalent 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 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 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 do most of what a combination of the other transport protocols can
achieve (eg TCP and DCCP or TCP and UDP). achieve (eg TCP and DCCP or TCP and UDP).
Like TCP, it provides ordered, reliable, connection-oriented, flow- Like TCP, it provides ordered, reliable, connection-oriented, flow-
controlled, congestion controlled data exchange. Unlike TCP, it does controlled, congestion controlled data exchange. Unlike TCP, it does
skipping to change at page 8, line 15 skipping to change at page 7, line 15
connection-oriented data exchange. connection-oriented data exchange.
SCTP also provides other services that none of the 3 transport SCTP also provides other services that none of the 3 transport
protocols mentioned above provide. These include: protocols mentioned above provide. These include:
o Multi-homing o Multi-homing
An SCTP connection can make use of multiple destination IP An SCTP connection can make use of multiple destination IP
addresses to communicate with its peer. addresses to communicate with its peer.
o Runtime IP address binding o Runtime IP address binding
With the SCTP ADDIP feature, a new address can be bound at With the SCTP Dynamic Address Reconfiguration ([RFC5061]) feature,
runtime. This allows for migration of endpoints without a new IP address can be bound at runtime. This allows for
restarting the association (valuable for high availability). migration of endpoints without restarting the association
(valuable for high availability).
o A range of reliability shades with congestion control o A range of reliability shades with congestion control
SCTP offers a range of services from full reliability to none, and SCTP offers a range of services from full reliability to none, and
from full ordering to none. With SCTP, on a per message basis, from full ordering to none. With SCTP, on a per message basis,
the application can specify a message's time-to-live. When the the application can specify a message's time-to-live. When the
expressed time expires, the message can be "skipped". expressed time expires, the message can be "skipped".
o Built-in heartbeats o Built-in heartbeats
SCTP has built-in heartbeat mechanism that validate the SCTP has built-in heartbeat mechanism that validate the
reachability of peer addresses. reachability of peer addresses.
o Multi-streaming o Multi-streaming
A known problem with TCP is head of line (HOL) blocking. If you A known problem with TCP is head of line (HOL) blocking. If you
have independent messages, TCP enforces ordering of such messages. have independent messages, TCP enforces ordering of such messages.
Loss at the head of the messages implies delays of delivery of Loss at the head of the messages implies delays of delivery of
subsequent packets. SCTP allows for defining upto 64K independent subsequent packets. SCTP allows for defining up to 64K
streams over the same socket connection, which are ordered independent streams over the same socket connection, which are
independently. ordered independently.
o Message boundaries with reliability o Message boundaries with reliability
SCTP allows for easier message parsing (just like UDP but with SCTP allows for easier message parsing (just like UDP but with
reliability built in) because it establishes boundaries on a PL reliability built in) because it establishes boundaries on a PL
message basis. On a TCP stream, one would have to use techniques message basis. On a TCP stream, one would have to use techniques
such peeking into the message to figure the boundaries. such peeking into the message to figure the boundaries.
o Improved SYN DOS protection o Improved SYN DOS protection
Unlike TCP, which does a 3 way connection setup handshake, SCTP Unlike TCP, which does a 3 way connection setup handshake, SCTP
does a 4 way handshake. This improves against SYN-flood attacks does a 4 way handshake. This improves against SYN-flood attacks
skipping to change at page 9, line 11 skipping to change at page 8, line 12
o Simpler transport events o Simpler transport events
An application (such as the TML) can subscribe to be notified of An application (such as the TML) can subscribe to be notified of
both local and remote transport events. Events that can be both local and remote transport events. Events that can be
subscribed-to include indication of association changes, subscribed-to include indication of association changes,
addressing changes, remote errors, expiry of timed messages, etc. addressing changes, remote errors, expiry of timed messages, etc.
These events are off by default and require explicit subscription. These events are off by default and require explicit subscription.
o Simplified replicasting o Simplified replicasting
Although SCTP does not allow for multicasting it allows for a Although SCTP does not allow for multicasting it allows for a
single message from an application to be sent to multiple peers. single message from an application to be sent to multiple peers.
This reduces the messaging that typically crosess different memory This reduces the messaging that typically crosses different memory
domains within a host. domains within a host (example in a kernel to user space domain of
an operating system).
4.1. Rationale for using SCTP for TML 4.1. Rationale for using SCTP for TML
SCTP has all the features required to provide a robust TML. As a SCTP has all the features required to provide a robust TML. As a
transport that is all-encompassing, it negates the need for having transport that is all-encompassing, it negates the need for having
multiple transport protocols, as has been suggested so far in the multiple transport protocols in order to satisfy the TML requirements
other proposals for TMLs. As a result it allows for simpler coding ([FE-PROTO] section 5). As a result it allows for simpler coding and
and therefore reduces a lot of the interoperability concerns. therefore reduces a lot of the interoperability concerns.
SCTP is also very mature and widely deployed completing the equation SCTP is also very mature and widely used making it a good choice for
that makes it a superior choice in comparison with other proposed ubiquitous deployment.
TMLs.
4.2. Meeting TML requirements 4.2. Meeting TML requirements
PL PL
+---------------------+ +----------------------+
| | | |
+-----------+---------+ +-----------+----------+
| TML API | TML API
TML | TML |
+-----------+----------+ +-----------+----------+
| | | | | |
| +------+------+ | | +------+------+ |
| | TML core | | | | TML core | |
| +-+----+----+-+ | | +-+----+----+-+ |
| | | | | | | | | |
| SCTP socket API | | SCTP socket API |
| | | | | | | | | |
skipping to change at page 10, line 34 skipping to change at page 9, line 34
| +------+------+ | | +------+------+ |
| | | | | |
| | | | | |
| +------+------+ | | +------+------+ |
| | IP | | | | IP | |
| +-------------+ | | +-------------+ |
+----------------------+ +----------------------+
Figure 3: The TML-SCTP interface Figure 3: The TML-SCTP interface
Figure 3 details the interfacing between the TML and SCTP and the Figure 3 details the interfacing between the PL and SCTP TML and the
internals of the SCTP TML. The core of the TML interfaces on its internals of the SCTP TML. The core of the TML interacts on its
north bound interface to the PL (utilizing the TML API). On the north-bound interface to the PL (utilizing the TML API). On the
southbound interface, the TML core interfaces to the SCTP layer south-bound interface, the TML core interfaces to the SCTP layer
utilizing the standard socket interface [Editorial: add here a utilizing the standard socket interface [XXX Editorial: add here a
reference to SCTP Sockets API doc]. There are three SCTP socket reference to SCTP Sockets API doc]. There are three SCTP socket
connections opened between any two PL layers (whether FE or CE). connections opened between any two PL endpoints (whether FE or CE).
4.2.1. SCTP TML Channels 4.2.1. SCTP TML Channels
+--------------------+ +--------------------+
| | | |
| TML core | | TML core |
| | | |
+-+-------+--------+-+ +-+-------+--------+-+
| | | | | |
| Med prio, | | Med prio, |
| Semi-reliable | | Semi-reliable |
| channel | | channel |
| | Low prio, | | Low prio,
| | Unreliable channel | | Unreliable
| | channel
| | | | | |
^ ^ ^ ^ ^ ^
| | | | | |
Y Y Y Y Y Y
High prio,| | | High prio,| | |
reliable | | | reliable | | |
channel | | | channel | | |
Y Y Y Y Y Y
+-+--------+--------+-+ +-+--------+--------+-+
| | | |
skipping to change at page 12, line 8 skipping to change at page 11, line 8
SCTP allows upto 64K streams to be sent over a single socket SCTP allows upto 64K streams to be sent over a single socket
interface. The authors initially envisioned using a single socket interface. The authors initially envisioned using a single socket
for all three channels (mapping a channel to an SCTP stream). This for all three channels (mapping a channel to an SCTP stream). This
simplifies programming of the TML as well as conserves use of SCTP simplifies programming of the TML as well as conserves use of SCTP
ports. ports.
Further analysis revealed head of line blocking issues with this Further analysis revealed head of line blocking issues with this
initial approach. Lower priority packets not needing reliable initial approach. Lower priority packets not needing reliable
delivery could block higher priority packets (needing reliable delivery could block higher priority packets (needing reliable
delivery) under congestion situation. This proposal alleviates that delivery) under congestion situation. For this reason, we elected to
problem by making the medium and low priority channels obsolete over go with mapping each of the three channels to a different SCTP socket
a period of time, but that is still insufficient to resolve the (instead of a different stream within a single socket).
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.
4.2.1.2. Higher Priority, Reliable channel 4.2.1.2. Higher Priority, Reliable channel
The higher priority channel uses a standard SCTP reliable socket on The higher priority (HP) channel uses a standard SCTP reliable socket
port 6700. It is used for CE solicited messages and their responses: on port 6700. It is used for CE solicited messages and their
responses:
1. ForCES configuration messages flowing from CE to FE and responses 1. ForCES configuration messages flowing from CE to FE and responses
from the FE to CE. from the FE to CE.
2. ForCES query messages flowing from CE to FE and responses from 2. ForCES query messages flowing from CE to FE and responses from
the FE to the CE. the FE to the CE.
Some events which require guaranteed delivery could also optionally It is recommended that the following PL messages use the HP channel
use this interface. An example of an event that would be prioritized for transport:
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).
4.2.1.3. Medium Priority, Mixed Reliable channel o Association Setup
The medium priority channel uses SCTP-PR on port 6701. Time limits o Association Setup Response
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 o Association Teardown
obsoleted over time. Events that are accumulative in nature and are
recoverable by the CE (by issuing a query to the FE) can tolerate o Config
lost events and therefore should this channel. Example a counter
that is monotonically incrementing fits to use this channel. o Config Response
o Query
o Query Response
4.2.1.3. Medium Priority, 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. 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 4.2.1.4. Lower Priority, Unreliable channel
The lower priority channel on SCTP port 6702 is used for redirect The lower priority (LP) channel uses SCTP port 6702. This channel
messages between the CE and FE. This channel also uses SCTP-PR with also uses SCTP-PR with lower timeout values than the MP channel. The
lower timeout values than the medium priority channel. The reason an reason an unreliable channel is used for redirect messages is to
unreliable channel is used for redirect messages is to allow the allow the control protocol at both the CE and its peer-endpoint to
control protocol at both the CE and its peer-endpoint to take charge take charge of how the end-to-end semantics of the said control
of how the end to end semantics of the said control protocol's protocol's operations. For example:
operations. For example:
1. Some control protocols are reliable in nature, therefore making 1. Some control protocols are reliable in nature, therefore making
this channel reliable introduces an extra layer of reliability this channel reliable introduces an extra layer of reliability
which could be harmful. So any end to end retransmits will which could be harmful. So any end-to-end retransmits will
happen from remote. happen from remote.
2. Some control protocols may desire to have obsolescence of 2. Some control protocols may desire to have obsolescence of
messages over retransmissions; making this channel reliable messages over retransmissions; making this channel reliable
contradicts that desire. contradicts that desire.
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 4.2.1.5. Scheduling of The 3 Channels
Strict priority work-conserving scheduling is used to process both on Strict priority work-conserving scheduling is used to process both on
sending and receving by the TML Core. This means that the higher sending and receiving (of the PL messages) by the TML Core as shown
priority messages are always processed first until there are no more in Figure 5.
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.
4.2.1.6. TML Parameterization This means that the HP messages are always processed first until
there are no more left. The 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).
TBA: This section will have a list of all parameters needed for The design intent of the SCTP TML is to tie prioritization as
booting the TML. described in Section 4.2.1.1 and transport congestion control to
provide implicit node congestion control. This is further detailed
in Section 5.
4.2.1.7. TML Bootstrapping 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
+--<--<---+--<--<----<----+-----<---<-----+
TBA: This section will show how the FE and CE side of bootstrapping. Figure 5: SCTP TML Strict Priority Scheduling
4.2.2. Satisfying Reliability Requirement 4.2.1.6. SCTP TML Parameterization
The following is a list of parameters needed for booting the TML. It
is expected these parameters will be extracted via the FEM/CEM
interface for each PL ID.
1. The IP address or a resolvable DNS/hostname of 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 As mentioned earlier, a shade of reliability ranges is possible in
SCTP. Therefore this requirement is met. SCTP. Therefore this requirement is met.
4.2.3. Satisfying Congestion Control Requirement 4.2.2.2. Satisfying Congestion Control Requirement
Congestion control is built into SCTP. Therefore, this requirement Congestion control is built into SCTP. Therefore, this requirement
is met. is met.
4.2.4. Satisfying Timeliness and prioritizationi Requirement 4.2.2.3. Satisfying Timeliness and Prioritization Requirement
By using 3 sockects in conjunction with the partial-reliability By using 3 sockets in conjunction with the partial-reliability
feature, both timeliness and prioritization can be achieved. feature, both timeliness and prioritization can be achieved.
4.2.5. Satisfying Addressing Requirement 4.2.2.4. Satisfying Addressing Requirement
SCTP can be told to replicast packets to multiple destinations. The There are no extra headers required for SCTP to fulfil this
TML will translate PL level addresses, to a variety of unicast IP requirement. SCTP can be told to replicast packets to multiple
addresses in order to emulate multicast and broadcast. Note, that destinations. The TML implementation will need to translate PL level
there are no extra headers required for SCTP. addresses, to a variety of unicast IP addresses in order to emulate
multicast and broadcast PL addresses.
4.2.6. Satisfying HA Requirement 4.2.2.5. Satisfying HA Requirement
Transport link resiliency is SCTP's strongest point (where it totally Transport link resiliency is one of SCTP's strongest point. Failure
outclasses all other TML proposals). Failure detection and recovery detection and recovery is built in, as mentioned earlier.
is built in as mentioned earlier.
o The SCTP multi-homing feature is used to provide path diversity. o The SCTP multi-homing feature is used to provide path diversity.
Should one of the peer IP addresses become unreachable, the Should one of the peer IP addresses become unreachable, the
other(s) are used without needing lower layer convergence other(s) are used without needing lower layer convergence
(routing, for example) or even the TML becoming aware. (routing, for example) or even the TML becoming aware.
o SCTP heartbeats and data transmission thresholds are used on a per o SCTP heartbeats and data transmission thresholds are used on a per
peer IP address to detect reachability faults. The faults could peer IP address to detect reachability faults. The faults could
be a result of an unreachable address or peer, which may be caused be a result of an unreachable address or peer, which may be caused
by a variety of reasons, like interface, network, or endpoint by a variety of reasons, like interface, network, or endpoint
failures. The cause of the fault is noted. failures. The cause of the fault is noted.
o With the ADDIP feature, one can migrate IP addresses to other o With the ADDIP feature, one can migrate IP addresses to other
nodes at runtime. This is not unlike the VRRP[RFC3768] protocol nodes at runtime. This is not unlike the VRRP[RFC3768] protocol
use. This feature is used in addition to multi-homing in a use. This feature is used in addition to multi-homing in a
planned migration of activity from one FE/CE to another. In such 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 a case, part of the provisioning recipe at the CE for replacing an
FE involves migrating activity of one FE to another. FE involves migrating activity of one FE to another.
4.2.7. Satisfying DOS Prevention Requirement 4.2.2.6. Satisfying DOS Prevention Requirement
Three separate streams (one per socket) are used within any FE-CE Three separate channels, one per socket, are used within any FE-CE
setup. The scheduling design for processing channels setup. The scheduling design for processing channels
(Section 4.2.1.5)is strict priority. This guarantees that lower (Section 4.2.1.5) is strict priority and ties transport and node
priority messages are starved if lack of resources happen. i.e under overload implicitly together. The HP channel work gets prioritized
congestion (which is likely to occur under DOS attack), redirected at the expense of the MP and LP channels in the presence of low
packets (from outside the NE) get very low priority and obsoleted in processing and bandwidth resource conditions. I.e., if redirected
short periods if the CE-FE path is congested without consuming packets (from outside the NE) attempt to overload the NE, they get
resources on the CE-FE path. assigned very low priority and 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.8. Satisfying Encapsulation Requirement 4.2.2.7. Satisfying Encapsulation Requirement
There is no extra encapsulation added by this TML. SCTP provides for There is no extra encapsulation added by the SCTP TML.
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 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 TML receives the ForCES message on the channel it was
sent on, it demultiplexes the message to the CE PL.
The CE PL, after some processing (in this example dealing with the
FE's association), sends to the TML the response. And as in the case
of FE PL, the CE TML picks the channel to send on before sending.
The processing of the ForCES 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, This document makes request of IANA to reserve SCTP ports 6700, 6701,
and 6702. and 6702.
6. Security Considerations 8. Security Considerations
When operating under a secured environment then the network The SCTP TML provides the following security services to the PL
administrator can turn off all the security functions. This feature level:
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 o A mechanism to authenticate ForCES CEs and FEs at transport level
environment, the operator has the choice of configuring either TLS in order to prevent the participation of unauthorized CEs and
[RFC2246] or IPSec [RFC2401] to provide needed security. For IPSec, unauthorized FEs in the control and data path processing of a
The security association between the CEs and FEs MUST be established ForCES NE.
before any ForCES protocol messages are exchanged between the CEs and
FEs.
6.1. TLS Usage for Securing TML o A mechanism to ensure message authentication of PL data and
headers transferred from the CE to FE (and vice-versa) in order to
prevent the injection of incorrect data into PL messages.
This section is applicable for CE or FE endpoints that use the TML o A mechanism to ensure the confidentiality of PL data and headers
with TLS [RFC2246] to secure communication. transferred from the CE to FE (and vice-versa), in order to
prevent disclosure of PL level information transported via the
TML.
Since CE is master and FEs are slaves, the FEs are TLS clients and Security choices provided by the TML are made by the operator and
CEs are TLS server. The endpoints that implement TLS MUST perform take effect during the pre-association phase of the ForCES protocol.
mutual authentication during TLS session establishment process. CE An operator may choose to use all, some or none of the security
must request certificate from FE and FE needs to pass the requested services provided by the TML in a CE-FE connection.
information.
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 a combination of
Transport Layer Security(TLS) [RFC4346] and Datagram Transport Layer
Security(DTLS) [RFC4347], or IP Security Protocol (IPsec) [RFC4301]
to provide needed security. It is recommended that the TLS/DTLS
combination is used and only in its absence should IPsec be
considered.
XXXX: Editors note: we should take note of RFC 3554 and 3436
8.1. TML 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
security requirements ([FE-PROTO]).
8.1.1. TLS Usage
Since in the ForCES architecture, the CE is master and FEs are
slaves, the FEs are D/TLS clients and CEs are 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 D/TLS MUST perform mutual authentication
during D/TLS session establishment process. Certificates are used to
achieve mutual authentication.
We recommend TLS-RSA-with-AES-128-CBC-SHA cipher suite. Although 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 consistency is expected it is possible for the CE or FE to negotiate
other TLS cipher suites. other D/TLS cipher suites.
6.2. IPSec Usage for securing TML 8.2. TML Security Services using IPsec
This section is applicable for CE or FE endpoints that use the TML XXXX: Editors note: We should review what RFCs to list as references
with IPSec [RFC2401] to secure their respective communication. IPSec (eg IKEv2, ESP etc).
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 IPsec is an IP level security scheme transparent to the higher-layer
details. applications and therefore can provide security for any transport
layer protocol. This gives IPsec the advantage that it can be used
to secure everything between the CE and FE without expecting the TML
implementation to be aware of the details.
7. Manageability Considerations The IPsec architecture is designed to provide message integrity and
message confidentiality outlined in the TML security 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 128-bit keys [RFC3602] for message confidentiality.
9. Manageability Considerations
TBA TBA
8. Acknowledgements 10. Acknowledgements
The authors would like to thank Joel Halpern, Michael Tuxen and Randy The authors would like to thank Joel Halpern, Michael Tuxen and Randy
Stewart for engaging us in discussions that have made this draft Stewart for engaging us in discussions that have made this draft
better. better.
9. References 11. References
9.1. Normative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 11.1. Normative References
RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
Internet Protocol", RFC 2401, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. 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 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003. of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
9.2. Informative References [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] [FE-MODEL]
Halpern, J., Deleganes, E., and J. Hadi Salim, "ForCES Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
Forwarding Element Model", February 2008. Model", October 2008.
[FE-PROTO] [FE-PROTO]
Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J.,
Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R.
Gopal, "ForCES Protocol Specification", March 2008. Gopal, "ForCES Protocol Specification", November 2008.
[TML-API] M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES [TML-API] M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES
Transport Mapping Layer (TML) Service Primitives", Transport Mapping Layer (TML) Service Primitives",
Feb. 2007. Feb. 2007.
Authors' Addresses Authors' Addresses
Jamal Hadi Salim Jamal Hadi Salim
ZNYX Networks Mojatatu Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@znyx.com Email: hadi@mojatatu.com
Kentaro Ogawa Kentaro Ogawa
NTT Corporation NTT Corporation
3-9-11 Midori-cho 3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Email: ogawa.kentaro@lab.ntt.co.jp 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.
 End of changes. 91 change blocks. 
293 lines changed or deleted 671 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/