draft-ietf-forces-sctptml-02.txt   draft-ietf-forces-sctptml-03.txt 
Network Working Group J. Hadi Salim Network Working Group J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Expires: August 2, 2009 K. Ogawa Expires: December 6, 2009 K. Ogawa
NTT Corporation NTT Corporation
January 29, 2009 June 4, 2009
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP based TML (Transport Mapping Layer) for ForCES protocol
draft-ietf-forces-sctptml-02 draft-ietf-forces-sctptml-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 August 2, 2009. This Internet-Draft will expire on December 6, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
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) [RFC4960] 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5
3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8
4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 9 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 8
4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 10 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 9
4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14 4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14
5. Channel work scheduling . . . . . . . . . . . . . . . . . . . 15 5. SCTP TML Channel work . . . . . . . . . . . . . . . . . . . . 16
5.1. FE Channel work scheduling . . . . . . . . . . . . . . . . 16 5.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 16
5.2. CE Channel work scheduling . . . . . . . . . . . . . . . . 17 5.2. Channel work scheduling . . . . . . . . . . . . . . . . . 16
6. Service Interface . . . . . . . . . . . . . . . . . . . . . . 17 5.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 17
6.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 18 5.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 17
6.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 19 5.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 18
6.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 20 5.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. Service Interface . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 19
8.1. TML Security Services using TLS and DTLS . . . . . . . . . 22 6.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.1. TLS Usage . . . . . . . . . . . . . . . . . . . . . . 22 6.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 21
8.2. TML Security Services using IPsec . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.2.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. Manageability Considerations . . . . . . . . . . . . . . . . . 23 8.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 8.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 10.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
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 5, line 26 skipping to change at page 5, line 26
Section 4.2.2 describes how the TML requirements are met. Section 4.2.2 describes how the TML requirements are met.
3.2.1. TML and PL Interfaces 3.2.1. TML and PL Interfaces
There are two interfaces to the PL and TML, both of which are out of There are two interfaces to the PL and TML, both of which are out of
scope for ForCES. The first one is the interface between the PL and scope for ForCES. The first one is the interface between the PL and
TML and the other is the CE Manager (CEM)/FE Manager (FEM)[RFC3746] 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 interface to both the PL and TML. Both interfaces are shown in
Figure 2. Figure 2.
[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 for a singular PL.
+----------------------------+ +----------------------------+
| +----------------------+ | | +----------------------+ |
| | | | | | | |
+---------+ | | PL Layer | | +---------+ | | PL Layer | |
| | | +----------------------+ | | | | +----------------------+ |
|FEM/CEM |<---->| ^ | |FEM/CEM |<---->| ^ |
| | | | | | | | | |
+---------+ | |TML API | +---------+ | |TML API |
| | | | | |
| V | | V |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
| | TML Layer | | | | TML Layer | |
| | | | | | | |
| +----------------------+ | | +----------------------+ |
+----------------------------+ +----------------------------+
Figure 2: The TML-PL interface Figure 2: The TML-PL interface
XXX - Editorial Note: 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.
Figure 2 also shows an interface referred to as CEM/FEM[RFC3746] Figure 2 also shows an interface referred to as CEM/FEM[RFC3746]
which is responsible for bootstrapping and parameterization of the which is responsible for bootstrapping and parameterization of the
TML. In its most basic form the CEM/FEM interface takes the form of 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- a simple static config file which is read on startup in the pre-
association phase. association phase.
Section 6 discusses in more details the service interfaces. Section 6 discusses in more details the service interfaces.
3.2.2. TML Parameterization 3.2.2. TML Parameterization
skipping to change at page 6, line 39 skipping to change at page 6, line 29
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)
4. SCTP TML overview 4. SCTP TML overview
SCTP [RFC2960] is an end-to-end transport protocol that is equivalent SCTP [RFC4960] 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 (e.g. 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.
Like UDP, it can provide unreliable, unordered data exchange. Unlike Like UDP, it can provide unreliable, unordered data exchange. Unlike
UDP, it does not provide multicast support UDP, it does not provide multicast support
Like DCCP, it can provide unreliable, ordered, congestion controlled, Like DCCP, it can provide unreliable, ordered, congestion controlled,
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.
skipping to change at page 9, line 38 skipping to change at page 9, line 5
| | IP | | | | IP | |
| +-------------+ | | +-------------+ |
+----------------------+ +----------------------+
Figure 3: The TML-SCTP interface Figure 3: The TML-SCTP interface
Figure 3 details the interfacing between the PL and SCTP TML 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 interacts 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
south-bound 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 [XXX Editorial: add here a utilizing the standard socket interface[SCTP-API] There are three
reference to SCTP Sockets API doc]. There are three SCTP socket SCTP socket connections opened between any two PL endpoints (whether
connections opened between any two PL endpoints (whether FE or CE). FE or CE).
4.2.1. SCTP TML Channels 4.2.1. SCTP TML Channels
+--------------------+ +--------------------+
| | | |
| TML core | | TML core |
| | | |
+-+-------+--------+-+ +-+-------+--------+-+
| | | | | |
| Med prio, | | Med prio, |
skipping to change at page 11, line 8 skipping to change at page 10, line 16
SCTP allows up to 64K streams to be sent over a single socket SCTP allows up to 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. For this reason, we elected to delivery) under congestion situation for an indeterminate period of
go with mapping each of the three channels to a different SCTP socket time (depending on how many outstanding lower priority packets are
(instead of a different stream within a single socket). pending). For this reason, we elected to go with mapping each of the
three channels to a different SCTP socket (instead of a different
stream within a single socket).
4.2.1.2. Higher Priority, Reliable channel 4.2.1.2. Higher Priority, Reliable channel
The higher priority (HP) channel uses a standard SCTP reliable socket The higher priority (HP) channel uses a standard SCTP reliable socket
on port 6700. It is used for CE solicited messages and their on port 6700. It is used for CE solicited messages and their
responses: 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.
It is recommended that the following PL messages use the HP channel It is recommended that PL priorities 4-7 be used for this channel and
for transport: that the following PL messages use the HP channel for transport:
o Association Setup o Association Setup
o Association Setup Response o Association Setup Response
o Association Teardown o Association Teardown
o Config o Config
o Config Response o Config Response
skipping to change at page 11, line 52 skipping to change at page 11, line 16
The medium priority (MP) channel uses SCTP-PR on port 6701. Time 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 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 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 obsoleted over time. Events that are accumulative in nature and
are recoverable by the CE (by issuing a query to the FE) can tolerate 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 lost events and therefore should use this channel. For example, a
generated event which carries the value of a counter that is generated event which carries the value of a counter that is
monotonically incrementing fits to use this channel. monotonically incrementing fits to use this channel.
It is recommended that the following PL messages use the MP channel It is recommended that PL priorities 2-3 be used for this channel and
for transport: that the following PL messages use the MP channel for transport:
o Event Notification o Event Notification
4.2.1.4. Lower Priority, Unreliable channel 4.2.1.4. Lower Priority, Unreliable channel
The lower priority (LP) channel uses SCTP port 6702. This channel The lower priority (LP) channel uses SCTP port 6702. This channel
also uses SCTP-PR with lower timeout values than the MP channel. The also uses SCTP-PR with lower timeout values than the MP channel. The
reason an unreliable channel is used for redirect messages is to reason an unreliable channel is used for redirect messages is to
allow the control protocol at both the CE and its peer-endpoint 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 take charge of how the end-to-end semantics of the said control
skipping to change at page 12, line 32 skipping to change at page 11, line 45
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 Given ForCES PL level heartbeats are traffic sensitive, sending them
over the LP channel also makes sense. If the other end is not over the LP channel also makes sense. If the other end is not
processing other channels it will eventually get heartbeats; and if processing other channels it will eventually get heartbeats; and if
it is busy processing other channels heartbeats will be obsoleted it is busy processing other channels heartbeats will be obsoleted
locally over time (and it does not matter if they did not make it). 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 It is recommended that PL priorities 0-1 be used for this channel and
for transport: that that the following PL messages use the LP channel for transport:
o Packet Redirect o Packet Redirect
o Heartbeats 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 receiving (of the PL messages) by the TML Core as shown sending and receiving (of the PL messages) by the TML Core as shown
in Figure 5. in Figure 5.
skipping to change at page 13, line 8 skipping to change at page 12, line 21
This means that the HP messages are always processed first until This means that the HP messages are always processed first until
there are no more left. The LP channel is processed only if a 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 channel that is higher priority than itself has no more messages left
to process. This means that under congestion situation, a higher to process. This means that under congestion situation, a higher
priority channel with sufficient messages that occupy the available priority channel with sufficient messages that occupy the available
bandwidth would starve lower priority channel(s). bandwidth would starve lower priority channel(s).
The design intent of the SCTP TML is to tie prioritization as The design intent of the SCTP TML is to tie prioritization as
described in Section 4.2.1.1 and transport congestion control to described in Section 4.2.1.1 and transport congestion control to
provide implicit node congestion control. This is further detailed provide implicit node congestion control. This is further detailed
in Section 5. in Section 5.2.
SCTP channel +----------+ SCTP channel +----------+
Work available | DONE +---<--<--+ Work available | DONE +---<--<--+
| +---+------+ | | +---+------+ |
Y ^ Y ^
| +-->--+ +-->---+ | | +-->--+ +-->---+ |
+-->-->-+ | | | | | +-->-->-+ | | | | |
| | | | | | ^ | | | | | | ^
| ^ ^ Y ^ Y | | ^ ^ Y ^ Y |
^ / \ | | | | | ^ / \ | | | | |
skipping to change at page 14, line 13 skipping to change at page 13, line 50
Figure 5: SCTP TML Strict Priority Scheduling Figure 5: SCTP TML Strict Priority Scheduling
4.2.1.6. SCTP TML Parameterization 4.2.1.6. SCTP TML Parameterization
The following is a list of parameters needed for booting the TML. It The following is a list of parameters needed for booting the TML. It
is expected these parameters will be extracted via the FEM/CEM is expected these parameters will be extracted via the FEM/CEM
interface for each PL ID. interface for each PL ID.
1. The IP address or a resolvable DNS/hostname of the CE/FE. 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 2. Whether to use IPsec or not. If IPsec is used, how to
parameterize the different required ciphers, keys etc as
described in Section 8.1
3. The HP SCTP port, as discussed in Section 4.2.1.2. The default
HP port value is 6700 (Section 7). HP port value is 6700 (Section 7).
3. The MP SCTP port, as discussed in Section 4.2.1.3. default MP 4. The MP SCTP port, as discussed in Section 4.2.1.3. The default
port value is 6701 (Section 7). MP port value is 6701 (Section 7).
4. The LP SCTP port, as discussed in Section 4.2.1.4. default LP 5. The LP SCTP port, as discussed in Section 4.2.1.4. The default
port value is 6702 (Section 7). LP port value is 6702 (Section 7).
4.2.2. Satisfying TML Requirements 4.2.2. Satisfying TML Requirements
[FE-PROTO] section 5 lists requirements that a TML needs to meet. [FE-PROTO] section 5 lists requirements that a TML needs to meet.
This section describes how the SCTP TML satisfies those requirements. This section describes how the SCTP TML satisfies those requirements.
4.2.2.1. Satisfying Reliability Requirement 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.
skipping to change at page 15, line 28 skipping to change at page 15, line 18
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.2.6. Satisfying DOS Prevention Requirement 4.2.2.6. Satisfying Node Overload Prevention Requirement
Three separate channels, one per socket, are used within any FE-CE The architecture of this TML defines three separate channels, one per
setup. The scheduling design for processing channels socket, to be used within any FE-CE setup. The scheduling design for
(Section 4.2.1.5) is strict priority and ties transport and node processing the TML channels (Section 4.2.1.5) is strict priority. A
overload implicitly together. The HP channel work gets prioritized fundamental desire of the strict prioritization is to ensure that
at the expense of the MP and LP channels in the presence of low more important work always gets node resources such as CPU and
processing and bandwidth resource conditions. I.e., if redirected bandwidth over lesser important work.
packets (from outside the NE) attempt to overload the NE, they get
assigned very low priority and obsoleted in short periods if either When a ForCES node CPU is overwhelmed because the incoming packet
the CE or FE is busy processing more important work or the CE-FE path rate is higher than it can keep up with, the channel queues grow and
is congested. Refer to Section 5 for details. transport congestion subsequently follows. By virtue of using SCTP,
the congestion is propagated back to the source of the incoming
packets and eventually alleviated.
The HP channel work gets prioritized at the expense of the MP which
gets prioritized over LP channels. The preferential scheduling only
kicks in when there is node overload regardless of whether there is
transport congestion. As a result of the preferential work
treatment, the ForCES node achieves a robust steady processing
capacity. Refer to Section 5.2 for details on scheduling.
For an example of how the overload prevention works: consider a
scenario where an overwhelming amount redirected packets (from
outside the NE) coming into the NE may overload the FE while it has
outstanding config work from the CE. In such a case, the FE, while
it is busy processing config requests from the CE ignores processing
the redirect packets on the LP channel. If enough redirect packets
accumulate, they are dropped either because the LP channel threshold
is exceeded or because they are obsoleted. If on the other hand, the
FE has successfully processed the higher priority channels and their
related work, then it can proceed and process the LP channel. So as
demonstrated in this case, the TML ties transport and node overload
implicitly together.
4.2.2.7. Satisfying Encapsulation Requirement 4.2.2.7. Satisfying Encapsulation Requirement
There is no extra encapsulation added by the SCTP TML. There is no extra encapsulation added by the SCTP TML.
In the future, should the need arise, a new SCTP extension/chunk can In the future, should the need arise, a new SCTP extension/chunk can
be defined to meet newer ForCES requirements [XXX: Editorial note: be defined to meet newer ForCES requirements [RFC4960].
provide reference to SCTP extensibility].
5. Channel work scheduling 5. SCTP TML Channel work
There are two levels of TML channel work within an NE when a ForCES
node (CE or FE) is connected to multiple other ForCES nodes:
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose
which of the peer nodes to process.
2. Node-level I/O work where a ForCES node, handles the three SCTP
TML channels separately for each single ForCES endpoint.
NE-level scheduling definition is left up to the implementation and
is considered out of scope for this document. Section 5.4 discuss
briefly some constraints that an implementor needs to worry about.
This document and in particular Section 5.1, Section 5.2 and
Section 5.3 discuss details of node-level I/O work.
5.1. SCTP TML Channel Initialization
It is recommended that the FE SHOULD do socket connections to the CE
in the order of incrementing priorities i.e. LP socket first,
followed by MP and ending with HP socket connection. The CE,
however, MUST NOT assume that there is ordering of socket connections
from any FE. Section 6.1 has more details on the expected
initialization of SCTP channel work.
5.2. Channel work scheduling
This section provides high level details of the scheduling view of This section provides high level details of the scheduling view of
the SCTP TML core (Section 4.2.1). A practical scheduler the SCTP TML core (Section 4.2.1). A practical scheduler
implementation takes care of many little details (such as timers, implementation takes care of many little details (such as timers,
work quanta, etc) not described in this document. The implementor is work quanta, etc) not described in this document. The implementor is
left to take care of those details. left to take care of those details.
The CE(s) and FE(s) are coupled together in the principles of the The CE(s) and FE(s) are coupled together in the principles of the
scheduling scheme described here to tie together node overload with scheduling scheme described here to tie together node overload with
transport congestion. The design intent is to provide the highest transport congestion. The design intent is to provide the highest
possible robust work throughput for the NE under any network or possible robust work throughput for the NE under any network or
processing congestion. processing congestion.
XXX (Editorial note): We need to solicit feedback whether it would 5.2.1. FE Channel work scheduling
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: The FE scheduling, in priority order, needs to I/O process:
1. The HP channel I/O in the following priority order: 1. The HP channel I/O in the following priority order:
1. Transmitting back to the CE any outstanding result of 1. Transmitting back to the CE any outstanding result of
executed work via the HP channel transmit path. executed work via the HP channel transmit path.
2. Taking new incoming work from the CE which creates ForCES 2. Taking new incoming work from the CE which creates ForCES
work to be executed by the FE. work to be executed by the FE.
skipping to change at page 17, line 5 skipping to change at page 17, line 35
from other NEs via external (to the NE) interfaces. After some from other NEs via external (to the NE) interfaces. After some
processing, such packets are sent to the CE. processing, such packets are sent to the CE.
It is worth emphasizing at this point again that the SCTP TML It is worth emphasizing at this point again that the SCTP TML
processes the channel work in strict priority. For example, as long 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 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 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 next priority work (which is to read new messages on the HP channel
incoming from the CE). incoming from the CE).
5.2. CE Channel work scheduling 5.2.2. CE Channel work scheduling
The CE scheduling, in priority order, needs to deal with: The CE scheduling, in priority order, needs to deal with:
1. The HP channel I/O in the following priority order: 1. The HP channel I/O in the following priority order:
1. Process incoming responses to requests of work it made to the 1. Process incoming responses to requests of work it made to the
FE(s). FE(s).
2. Transmitting any outstanding HP work it needs for the FE(s) 2. Transmitting any outstanding HP work it needs for the FE(s)
to complete. to complete.
skipping to change at page 17, line 33 skipping to change at page 18, line 15
4. Incoming Redirect work in the form of control packets that come 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). 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 It is worth to repeat for emphasis again that the SCTP TML processes
the channel work in strict priority. For example, if there are the channel work in strict priority. For example, if there are
messages incoming from an FE on the HP channel, they will be messages incoming from an FE on the HP channel, they will be
processed first until there are no more left before processing the processed first until there are no more left before processing the
next priority work which is to transmit any outstanding HP channel next priority work which is to transmit any outstanding HP channel
messages going to the FE. messages going to the FE.
6. Service Interface 5.3. SCTP TML Channel Termination
XXX - Editorial Note and repeated emphasis: There is some concern Section 6.2 describes a controlled disassociation of the FE from the
(and confusion) about defining APIs in ForCES. So at the moment the NE.
future of [TML-API] is unknown and we will remove references to it in
future revisions of this document. It is also possible for connectivity to be lost between the FE and CE
on one or more sockets. In cases where SCTP multi-homing features
are used for path availability, the disconnection of a socket will
only occur if all paths are unreachable; otherwise, SCTP will ensure
reachability. In the situation of a total connectivity loss of even
one SCTP socket, it is recommended that the FE and CE SHOULD assume a
state equivalent to ForCES Association Teardown being issued and
follow the sequence described in Section 6.2.
A CE could also disconnect sockets to an FE to indicate an "emergency
teardown". The "emergency teardown" may be necessary in cases when a
CE needs to disconnect an FE but knows that an FE is busy processing
a lot of outstanding commands (some of which the FE hasn't got around
to processing yet). By virtue of the CE closing the connections, the
FE will immediately be asynchronously notified and will not have to
process any outstanding commands from the CE.
5.4. SCTP TML NE level channel scheduling
In handling NE-level I/O work, an implementation needs to worry about
being both fair and robust across peer ForCES nodes.
Fairness is desired so that each peer node makes progress across the
NE. For the sake of illustration consider two FEs connected to a CE;
whereas one FE has a few HP messages that need to be processed by the
CE, another may have infinite HP messages. The scheduling scheme may
decide to use a quota scheduling system to ensure that the second FE
does not hog the CE cycles.
Robustness is desired so that the NE does not succumb to a DoS attack
from hostile entities and always achieves a maximum stable workload
processing level. For the sake of illustration consider again two
FEs connected to a CE. Consider FE1 as having a large number of HP
and MP messages and FE2 having a large number of MP and LP messages.
The scheduling scheme needs to ensure that while FE1 always gets its
messages processed, at some point we allow FE2 messages to be
processed. A promotion and preemption based scheduling could be used
by the CE to resolve this issue.
6. Service Interface
This section provides high level service interface between FEM/CEM This section provides high level service interface between FEM/CEM
and TML, the PL and TML, and between local and remote TMLs. The and TML, the PL and TML, and between local and remote TMLs. The
intent of this interface discussion is to provide general guidelines. intent of this interface discussion is to provide general guidelines.
The implementer is expected to worry about details and even follow a The implementer is expected to worry about details and even follow a
different approach if needed. different approach if needed.
The theory of operation for the PL-TML service is as follows: 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 1. The PL starts up and bootstraps the TML. The end result of a
skipping to change at page 22, line 33 skipping to change at page 23, line 39
Security choices provided by the TML are made by the operator and Security choices provided by the TML are made by the operator and
take effect during the pre-association phase of the ForCES protocol. take effect during the pre-association phase of the ForCES protocol.
An operator may choose to use all, some or none of the security An operator may choose to use all, some or none of the security
services provided by the TML in a CE-FE connection. services provided by the TML in a CE-FE connection.
When operating under a secured environment, or for other operational When operating under a secured environment, or for other operational
concerns (in some cases performance issues) the operator may turn off concerns (in some cases performance issues) the operator may turn off
all the security functions between CE and FE. all the security functions between CE and FE.
The operator has the choice of configuring either a combination of IP Security Protocol (IPsec) [RFC4301] is used to provide needed
Transport Layer Security(TLS) [RFC4346] and Datagram Transport Layer security mechanisms.
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
consistency is expected it is possible for the CE or FE to negotiate
other D/TLS cipher suites.
8.2. TML Security Services using IPsec
XXXX: Editors note: We should review what RFCs to list as references
(eg IKEv2, ESP etc).
IPsec is an IP level security scheme transparent to the higher-layer IPsec is an IP level security scheme transparent to the higher-layer
applications and therefore can provide security for any transport applications and therefore can provide security for any transport
layer protocol. This gives IPsec the advantage that it can be used layer protocol. This gives IPsec the advantage that it can be used
to secure everything between the CE and FE without expecting the TML to secure everything between the CE and FE without expecting the TML
implementation to be aware of the details. implementation to be aware of the details.
The IPsec architecture is designed to provide message integrity and The IPsec architecture is designed to provide message integrity and
message confidentiality outlined in the TML security requirements message confidentiality outlined in the TML security requirements
([FE-PROTO]). Mutual authentication and key exchange protocol ([FE-PROTO]). Mutual authentication and key exchange protocol are
Internet Key Exchange (IKE)[RFC4109]. provided by Internet Key Exchange (IKE)[RFC4109].
8.2.1. IPsec Usage 8.1. IPsec Usage
It is recommended that the following options be used for consistency A ForCES FE or CE MUST support the following:
(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 o Internet Key Exchange (IKE)[RFC4109] with certificates for
endpoint authentication. endpoint authentication.
o Transport Mode Encapsulating Security Payload (ESP) o Transport Mode Encapsulating Security Payload (ESP)[RFC4303].
o HMAC-SHA1-96 [RFC2404] for message integrity protection o HMAC-SHA1-96 [RFC2404] for message integrity protection
o AES-CBC with 128-bit keys [RFC3602] for message confidentiality. o AES-CBC with 128-bit keys [RFC3602] for message confidentiality.
9. Manageability Considerations o Replay protection[RFC4301].
TBA It is expected to be possible for the CE or FE to be operationally
configured to negotiate other cipher suites and even use manual
keying.
10. Acknowledgements 8.1.1. SAD and SPD setup
The authors would like to thank Joel Halpern, Michael Tuxen and Randy To minimize the operational configuration it is recommended that only
Stewart for engaging us in discussions that have made this draft the IANA issued SCTP protocol number(132) be used as a selector in
better. the Security Policy Database (SPD) for ForCES. In such a case only a
single SPD and SAD entry is needed.
11. References It should be straightforward to extend such a policy to alternatively
use the 3 SCTP TML port numbers as SPD selectors. But as noted above
this choice will require increased number of SPD entries.
11.1. Normative References In scenarios where multiple IP addresses are used within a single
association, and there is desire to configure different policies on a
per IP address, then it is recommended to follow [RFC3554]
9. Acknowledgements
The authors would like to thank Joel Halpern, Michael Tuxen, Randy
Stewart and Evangelos Haleplidis for engaging us in discussions that
have made this draft better.
10. References
10.1. Normative References
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
IANA Considerations Section in RFCs", BCP 26, RFC 2434, Stewart, "On the Use of Stream Control Transmission
October 1998. Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, Algorithm and Its Use with IPsec", RFC 3602,
September 2003. September 2003.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version
1 (IKEv1)", RFC 4109, May 2005. 1 (IKEv1)", RFC 4109, May 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
(TLS) Protocol Version 1.1", RFC 4346, April 2006. RFC 4303, December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
Security", RFC 4347, April 2006. RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
September 2007. September 2007.
11.2. Informative References 10.2. Informative References
[FE-MODEL] [FE-MODEL]
Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
Model", October 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", November 2008. Gopal, "ForCES Protocol Specification", November 2008.
[TML-API] M. Wang, W., Hadi Salim, J., and A. Audu, "ForCES [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
Transport Mapping Layer (TML) Service Primitives", of IP Control and Forwarding", RFC 3654, November 2003.
Feb. 2007.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[SCTP-API]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Feb. 2009.
Authors' Addresses Authors' Addresses
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@mojatatu.com Email: hadi@mojatatu.com
 End of changes. 47 change blocks. 
158 lines changed or deleted 220 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/