draft-ietf-forces-sctptml-00.txt   draft-ietf-forces-sctptml-01.txt 
Network Working Group J. Hadi Salim Network Working Group J. Hadi Salim
Internet-Draft ZNYX Networks Internet-Draft ZNYX Networks
Expires: May 12, 2008 K. Ogawa Expires: January 15, 2009 K. Ogawa
NTT Network Service Systems NTT Corporation
Laboratories July 14, 2008
November 9, 2007
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP based TML (Transport Mapping Layer) for ForCES protocol
draft-ietf-forces-sctptml-00 draft-ietf-forces-sctptml-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at page 1, line 36 skipping to change at page 1, line 35
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 May 12, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. The TML layer . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The TML layer . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. TML Parameterization . . . . . . . . . . . . . . . . . 6 3.2.1. TML Parameterization . . . . . . . . . . . . . . . . . 6
3.3. The TML-PL interface . . . . . . . . . . . . . . . . . . . 6 3.3. The TML-PL interface . . . . . . . . . . . . . . . . . . . 6
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Introduction to SCTP . . . . . . . . . . . . . . . . . . . 7 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 9
4.2. Rationale for using SCTP for TML . . . . . . . . . . . . . 9 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 10
4.3. Meeting TML requirements . . . . . . . . . . . . . . . . . 9 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 11
4.3.1. Reliability . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Satisfying Reliability Requirement . . . . . . . . . . 13
4.3.2. Congestion control . . . . . . . . . . . . . . . . . . 10 4.2.3. Satisfying Congestion Control Requirement . . . . . . 13
4.3.3. Timeliness and prioritization . . . . . . . . . . . . 10 4.2.4. Satisfying Timeliness and prioritizationi
4.3.4. Addressing . . . . . . . . . . . . . . . . . . . . . . 10 Requirement . . . . . . . . . . . . . . . . . . . . . 13
4.3.5. HA . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.5. Satisfying Addressing Requirement . . . . . . . . . . 14
4.3.6. DOS prevention . . . . . . . . . . . . . . . . . . . . 11 4.2.6. Satisfying HA Requirement . . . . . . . . . . . . . . 14
4.3.7. Encapsulation . . . . . . . . . . . . . . . . . . . . 11 4.2.7. Satisfying DOS Prevention Requirement . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4.2.8. Satisfying Encapsulation Requirement . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Manageability Considerations . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. TLS Usage for Securing TML . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. IPSec Usage for securing TML . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7. Manageability Considerations . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
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
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 TCP, IP, ATM, Ethernet,
etc), and how to achieve and implement reliability, multicast, etc), and how to achieve and implement reliability, multicast,
ordering, 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 is defining the architecture and protocol for separation
of control and forwarding elements in network elements such as of Control Elements(CE) and Forwarding Elements(FE) in Network
routers. [RFC3654] and [RFC3746] respectively define architectural Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively
and protocol requirements for the communication between CE and FE. define architectural and protocol requirements for the communication
The ForCES protocol layer specification [FE-PROTO] describes the between CE and FE. The ForCES protocol layer specification
protocol semantics and workings. The ForCES protocol layer operates [FE-PROTO] describes the protocol semantics and workings. The ForCES
on top of an inter-connect hiding layer known as the TML. The protocol layer operates on top of an inter-connect hiding layer known
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. [FE-PROTO] and this section in order to provide clarity to the reader
of this document.
The ForCES layout constitutes two pieces: the PL and TML layer. This The ForCES layout constitutes two pieces: the PL and TML layer. This
is depicted in Figure 1. is depicted in Figure 1.
+---------------------------------------------- +----------------------------------------------+
| CE PL | | CE PL |
+---------------------------------------------- +----------------------------------------------+
| CE TML | | CE TML |
+---------------------------------------------- +----------------------------------------------+
^ ^
| |
ForCES | (i.e. Forces data + control ForCES | (i.e. Forces data + control
PL | packets ) PL | packets )
messages | messages |
over | over |
specific | specific |
TML | TML |
encaps | encapsulation|
and | and |
transport | 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 layer 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 Layer is necessary
to connect two ForCES PL layers as shown in Figure 1. to connect two ForCES PL layers as shown in Figure 1.
Both the PL and TML are standardized by the IETF. While only one PL 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 peers (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, the PL delivers its messages to the TML. The TML
then delivers the PL message to the destination peer TML(s) as then delivers the PL message to the destination peer TML(s) as
defined by the addressing in the PL message. defined by the addressing in the PL message.
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). destination PL layer(s) (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 layer 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. An FE uses the PL layer to throw various subscribed-to
events to the CE PL layer as well as respond to various status 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 requests issued from the CE PL. The CE configures both the FE and
associated LFBs attributes using the PL layer. In addition the CE associated LFBs attributes using the PL layer. In addition the CE
skipping to change at page 6, line 21 skipping to change at page 6, line 23
The TML SHOULD will be able to handle up to 8 priority levels The TML SHOULD will be able to handle up to 8 priority levels
needed by the PL and will provide preferential treatment. needed by the PL and will provide preferential treatment.
The TML needs to define how this is achieved. The TML needs to define how this is achieved.
8. Protection against DoS attacks 8. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6 As described in the Requirements RFC 3654, section 6
It is expected more than one TML will be standardized. The different It is expected more than one TML will be standardized. The different
TMLs each could implement things differently based on capabilities of TMLs each could implement things differently based on capabilities of
underlying media and transport. However, since each TML is underlying media and transport. However, since each TML is
standardized, interoperability is guaranteed as long as both standardized, interoperability is guaranteed only as long as both
endpoints support the same TML. endpoints support the same TML.
3.2.1. TML Parameterization 3.2.1. 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
skipping to change at page 7, line 5 skipping to change at page 7, line 7
3.3. The TML-PL interface 3.3. The TML-PL interface
[TML-API] defines an interface between the PL and the TML layers. [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 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 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 makes it easy to plug in different TMLs over time. It also allows
for simplified TML parameterization requirement stated in for simplified TML parameterization requirement stated in
Section 3.2.1. Section 3.2.1.
,''''''''''''''''''''''| +----------------------+
| | | |
| PL Layer | | PL Layer |
| | | |
|........ .............| +----------------------+
^ ^
| |
| TML API | TML API
| |
| |
V V
,''''''''''''''''''''''`. +----------------------+
| | | |
| TML Layer | | TML Layer |
| | | |
'`''''''''''''''''''''''' +----------------------+
Figure 2: The TML-PL interface Figure 2: The TML-PL interface
We are going to assume the existence of such an interface and not 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 discuss it further. The reader is encouraged to read [TML-API] as a
background. background.
4. SCTP TML overview 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.1. Introduction to SCTP 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
not provide byte streaming and instead provides message boundaries. not provide byte streaming and instead provides message boundaries.
skipping to change at page 8, line 35 skipping to change at page 8, line 40
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 upto 64K independent
streams over the same socket connection, which are ordered streams over the same socket connection, which are ordered
independently. 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 peek into the message basis. On a TCP stream, one would have to use techniques
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
because listening sockets do not set up state until a connection because listening sockets do not set up state until a connection
is validated. is validated.
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 such as indication both local and remote transport events. Events that can be
of association changes, addressing changes, remote errors, expiry subscribed-to include indication of association changes,
of timed messages, etc, are off by default and require explicit addressing changes, remote errors, expiry of timed messages, etc.
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 crosess different memory
domains within a host. domains within a host.
4.2. 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, as has been suggested so far in the
other proposals for TMLs. As a result it allows for simpler coding other proposals for TMLs. As a result it allows for simpler coding
and therefore reduces a lot of the interoperability concerns. and 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 deployed completing the equation
that makes it a superior choice in comparison with other proposed that makes it a superior choice in comparison with other proposed
TMLs. TMLs.
4.3. Meeting TML requirements 4.2. Meeting TML requirements
,''''''''''''''''''''| PL
| | +---------------------+
| PL |
| | | |
|........ .+.........| +-----------+---------+
| | TML API
+ TML API TML |
| +-----------+----------+
,''''''''''+'''''''''`. | | |
| +------+------+ |
| | TML core | |
| +-+----+----+-+ |
| | | | |
| SCTP socket API |
| | | | |
| | | | |
| +-+----+----+-+ |
| | SCTP | |
| +------+------+ |
| | |
| | |
| +------+------+ |
| | IP | |
| +-------------+ |
+----------------------+
Figure 3: The TML-SCTP interface
Figure 3 details the interfacing between the TML and SCTP and the
internals of the SCTP TML. The core of the TML interfaces on its
north bound interface to the PL (utilizing the TML API). On the
southbound interface, the TML core interfaces to the SCTP layer
utilizing the standard socket interface [Editorial: add here a
reference to SCTP Sockets API doc]. There are three SCTP socket
connections opened between any two PL layers (whether FE or CE).
4.2.1. SCTP TML Channels
+--------------------+
| | | |
| TML | | TML core |
| | | |
'`'''''''''+''''''''''' +-+-------+--------+-+
| | | |
+ SCTP socket API | Med prio, |
| | Semi-reliable |
,''''''''''+'''''''''`. | channel |
| | Low prio,
| | Unreliable channel
| | |
^ ^ ^
| | |
Y Y Y
High prio,| | |
reliable | | |
channel | | |
Y Y Y
+-+--------+--------+-+
| | | |
| SCTP | | SCTP |
| (over IP) |
| | | |
'`''''''''''''''''''''' +---------------------+
Figure 3: The TML-SCTP interface Figure 4: The TML-SCTP channels
Figure 3 above shows the interfacing between the TML and SCTP. There
is only one socket connection open with two streams used. The first
stream which is high priority will be dedicated for configuration
data and the second lower priority stream is used for data path
redirect. The TML will use information passed by the TML API to
select which of the two streams to use when sending. The TML will
also subscribe to events from SCTP associated with the two streams.
4.3.1. Reliability 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 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 the medium and low priority channels obsolete over
a period of time, but that is still insufficient to resolve the
outstanding HOL issue.
XXX: Talk here about Michael Tuxen's approach which will allow for
SCTP to prioritize streams within a single socket. Unfortunately,
until that approach completes standardization effort we cannot
recomend its use for ForCES TML.
4.2.1.2. Higher Priority, Reliable channel
The higher priority channel uses a standard SCTP reliable socket on
port 6700. It is used for CE solicited messages and their responses:
1. ForCES configuration messages flowing from CE to FE and responses
from the FE to CE.
2. ForCES query messages flowing from CE to FE and responses from
the FE to the CE.
Some events which require guaranteed delivery could also optionally
use this interface. An example of an event that would be prioritized
and delivered on this channel would be a PL heartbeat (in a scenario
when the first few HBs fail to make it to the destination).
4.2.1.3. Medium Priority, Mixed Reliable channel
The medium priority channel uses SCTP-PR on port 6701. Time limits
on how long a message is valid are set on each outgoing message.
This channel is used for events from the FE to the CE that are
obsoleted over time. Events that are accumulative in nature and are
recoverable by the CE (by issuing a query to the FE) can tolerate
lost events and therefore should this channel. Example a counter
that is monotonically incrementing fits to use this channel.
4.2.1.4. Lower Priority, Unreliable channel
The lower priority channel on SCTP port 6702 is used for redirect
messages between the CE and FE. This channel also uses SCTP-PR with
lower timeout values than the medium priority channel. The reason an
unreliable channel is used for redirect messages is to allow the
control protocol at both the CE and its peer-endpoint to take charge
of how the end to end semantics of the said control protocol's
operations. For example:
1. Some control protocols are reliable in nature, therefore making
this channel reliable introduces an extra layer of reliability
which could be harmful. So any end to end retransmits will
happen from remote.
2. Some control protocols may desire to have obsolescence of
messages over retransmissions; making this channel reliable
contradicts that desire.
4.2.1.5. Scheduling of The 3 Channels
Strict priority work-conserving scheduling is used to process both on
sending and receving by the TML Core. This means that the higher
priority messages are always processed first until there are no more
left. The lower priority channel is processed only if a channel that
is higher priority than itself has no more messages left to process.
This means that under congestion situation, a higher priority channel
with sufficient messages that occupy the available bandwidth would
starve lower priority channel(s). The authors feel this is justified
given the choice of the messaging prioritization as described above.
4.2.1.6. TML Parameterization
TBA: This section will have a list of all parameters needed for
booting the TML.
4.2.1.7. TML Bootstrapping
TBA: This section will show how the FE and CE side of bootstrapping.
4.2.2. Satisfying Reliability Requirement
As mentioned earlier, a shade of reliability ranges is possible in As mentioned earlier, a shade of reliability ranges is possible in
SCTP. Therefore this requirement is met. SCTP. Therefore this requirement is met.
Redirected control traffic in ForCES is not expected to be reliably 4.2.3. Satisfying Congestion Control Requirement
delivered but MUST at the same time be congestion aware. This
requirement is also met by SCTP.
4.3.2. Congestion control
Congestion control is built into SCTP. Therefore, this requirement Congestion control is built into SCTP. Therefore, this requirement
is met. is met.
4.3.3. Timeliness and prioritization 4.2.4. Satisfying Timeliness and prioritizationi Requirement
By using multiple streams in conjunction with the partial-reliability By using 3 sockects in conjunction with the partial-reliability
feature, both timeliness and prioritization can be achieved. feature, both timeliness and prioritization can be achieved.
4.3.4. Addressing 4.2.5. Satisfying Addressing Requirement
SCTP can be told to replicast packets to multiple destinations. The SCTP can be told to replicast packets to multiple destinations. The
TML will translate PL level addresses, to a variety of unicast IP TML will translate PL level addresses, to a variety of unicast IP
addresses in order to emulate multicast and broadcast. Note, addresses in order to emulate multicast and broadcast. Note, that
however, unlike other proposed TMLs, that there are no extra headers there are no extra headers required for SCTP.
required for SCTP.
4.3.5. HA 4.2.6. Satisfying HA Requirement
Transport link resiliency is SCTP's strongest point (where it totally Transport link resiliency is SCTP's strongest point (where it totally
outclasses all other TML proposals). Failure detection and recovery outclasses all other TML proposals). Failure 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.
skipping to change at page 11, line 15 skipping to change at page 14, line 36
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.3.6. DOS prevention 4.2.7. Satisfying DOS Prevention Requirement
Two separate streams are used within any FE-CE setup: the higher Three separate streams (one per socket) are used within any FE-CE
priority one is for configuration and the lower priority one for data setup. The scheduling design for processing channels
redirection. The design is strict priority to further guarantee that (Section 4.2.1.5)is strict priority. This guarantees that lower
lower priority is starved if lack of resources happen. priority messages are starved if lack of resources happen. i.e under
congestion (which is likely to occur under DOS attack), redirected
packets (from outside the NE) get very low priority and obsoleted in
short periods if the CE-FE path is congested without consuming
resources on the CE-FE path.
4.3.7. Encapsulation 4.2.8. Satisfying Encapsulation Requirement
There is no extra encapsulation added by this TML. SCTP provides for There is no extra encapsulation added by this TML. SCTP provides for
extensions to be added to it by defining new chunks. In the future, 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 should the need arise, a new SCTP extension can be defined to meet
newer ForCES requirements. newer ForCES requirements.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes request of IANA to reserve SCTP ports 6700, 6701,
and 6702.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations 6. Security Considerations
TBA: how to use TLS,IPSEC When operating under a secured environment then the network
administrator can turn off all the security functions. This feature
is configured during the pre-association phase of the protocol. This
mode is called "no security" mode of operation.
When the CEs, FEs are running over IP networks or in an insecure
environment, the operator has the choice of configuring either TLS
[RFC2246] or IPSec [RFC2401] to provide needed security. For IPSec,
The security association between the CEs and FEs MUST be established
before any ForCES protocol messages are exchanged between the CEs and
FEs.
6.1. TLS Usage for Securing TML
This section is applicable for CE or FE endpoints that use the TML
with TLS [RFC2246] to secure communication.
Since CE is master and FEs are slaves, the FEs are TLS clients and
CEs are TLS server. The endpoints that implement TLS MUST perform
mutual authentication during TLS session establishment process. CE
must request certificate from FE and FE needs to pass the requested
information.
We recommend TLS-RSA-with-AES-128-CBC-SHA cipher suite. Although
consistency is expected it is possible for the CE or FE to negotiate
other TLS cipher suites.
6.2. IPSec Usage for securing TML
This section is applicable for CE or FE endpoints that use the TML
with IPSec [RFC2401] to secure their respective communication. IPSec
is transparent to the higher-layer applications and can provide
security for any transport layer protocol. This mechanism is can be
used to secure just the control or both the control and the data
channel simultaneously.
Editorial Note: We need to flesh the security section with more
details.
7. Manageability Considerations 7. Manageability Considerations
TBA TBA
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Joel Halpern, Michael Tuxen and Randy
Stewart for engaging us in discussions that have made this draft
better.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [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.
[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 9.2. Informative References
[FE-MODEL] [FE-MODEL]
Halpern, J. and E. Deleganes, "ForCES Forwarding Element Halpern, J., Deleganes, E., and J. Hadi Salim, "ForCES
Model", Oct. 2007. Forwarding Element Model", February 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", July 2007. Gopal, "ForCES Protocol Specification", March 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 ZNYX Networks
Ottawa, Ontario Ottawa, Ontario
skipping to change at page 13, line 4 skipping to change at page 17, line 17
Feb. 2007. Feb. 2007.
Authors' Addresses Authors' Addresses
Jamal Hadi Salim Jamal Hadi Salim
ZNYX Networks ZNYX Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@znyx.com Email: hadi@znyx.com
Kentaro Ogawa Kentaro Ogawa
NTT Network Service Systems Laboratories 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 Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 14, line 44 skipping to change at line 755
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 53 change blocks. 
113 lines changed or deleted 289 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/