draft-ietf-forces-sctptml-08.txt   rfc5811.txt 
Network Working Group J. Hadi Salim Internet Engineering Task Force (IETF) J. Hadi Salim
Internet-Draft Mojatatu Networks Request for Comments: 5811 Mojatatu Networks
Intended status: Standards Track K. Ogawa Category: Standards Track K. Ogawa
Expires: July 23, 2010 NTT Corporation ISSN: 2070-1721 NTT Corporation
January 19, 2010 March 2010
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP-Based Transport Mapping Layer (TML) for the
draft-ietf-forces-sctptml-08 Forwarding and Control Element Separation (ForCES) Protocol
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 (Forwarding and Control Element Separation) protocol.
SCTP (Stream Control Transmission Protocol) and also describes how It explains the rationale for choosing the SCTP (Stream Control
this TML addresses all the requirements required by and the ForCES Transmission Protocol) and also describes how this TML addresses all
protocol. the requirements required by and the ForCES protocol.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on July 23, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5811.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions .....................................................3
3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 4 3. Protocol Framework Overview .....................................4
3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The PL .....................................................5
3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. The TML ....................................................5
3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 6 3.2.1. TML and PL Interfaces ...............................5
3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 7 3.2.2. TML Parameterization ................................6
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 8 4. SCTP TML Overview ...............................................7
4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8 4.1. Rationale for Using SCTP for TML ...........................7
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 . . . . . . . . . . . . . 15 4.2.2. Satisfying TML Requirements ........................14
5. SCTP TML Channel Work . . . . . . . . . . . . . . . . . . . . 17 5. SCTP TML Channel Work ..........................................16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations ............................................16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations ........................................17
7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. IPsec Usage ...............................................17
7.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 19 7.1.1. SAD and SPD Setup ..................................18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements ...............................................18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References .....................................................19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References ......................................19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References ....................................20
Appendix A. Suggested SCTP TML Channel Work Implementation . . . 21 Appendix A. Suggested SCTP TML Channel Work Implementation .......21
A.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 21 A.1. SCTP TML Channel Initialization ...........................21
A.2. Channel work scheduling . . . . . . . . . . . . . . . . . 22 A.2. Channel Work Scheduling ...................................21
A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 22 A.2.1. FE Channel Work Scheduling ............................21
A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 22 A.2.2. CE Channel Work Scheduling ............................22
A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 23 A.3. SCTP TML Channel Termination ..............................23
A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 24 A.4. SCTP TML NE-Level Channel Scheduling ......................23
Appendix B. Suggested Service Interface . . . . . . . . . . . . . 24 Appendix B. Suggested Service Interface ..........................24
B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 25 B.1. TML Bootstrapping .........................................24
B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 26 B.2. TML Shutdown ..............................................26
B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 27 B.3. TML Sending and Receiving .................................27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Definitions 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The ForCES (Forwarding and Control Element Separation) working group
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this in the IETF defines the architecture and protocol for separation of
document are to be interpreted as described in RFC 2119. control elements (CEs) and forwarding elements (FEs) in network
elements (NEs) such as routers. [RFC3654] and [RFC3746],
respectively, define architectural and protocol requirements for the
communication between CEs and FEs. The ForCES protocol layer
specification [RFC5810] describes the protocol semantics and
workings. The ForCES protocol layer operates on top of an inter-
connect hiding layer known as the TML. The relationship is
illustrated in Figure 1.
The following definitions are taken from [RFC3654]and [RFC3746]: This document defines the SCTP-based TML for the ForCES protocol
layer. It also addresses all the requirements for the TML including
security, reliability, and etc., as defined in [RFC5810].
Logical Functional Block (LFB) -- A template that represents a fine- 2. Definitions
grained, logically separate aspects of FE processing.
ForCES Protocol -- The protocol used at the Fp reference point in the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
ForCES Framework in [RFC3746]. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
ForCES Protocol Layer (ForCES PL) -- A layer in the ForCES The following definitions are taken from [RFC3654] and [RFC3746]:
architecture that embodies the ForCES protocol and the state transfer
mechanisms as defined in [I-D.ietf-forces-protocol].
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in LFB: Logical Functional Block. A template that
ForCES protocol architecture that specifically addresses the protocol represents a fine-grained, logically separate
message transportation issues, such as how the protocol messages are aspect of FE processing.
mapped to different transport media (like SCTP, IP, TCP, UDP, ATM,
Ethernet, etc), and how to achieve and implement reliability,
security, etc.
2. Introduction ForCES Protocol: The protocol used at the Fp reference point in the
ForCES Framework in [RFC3746].
The ForCES (Forwarding and Control Element Separation) working group ForCES PL: ForCES Protocol Layer. A layer in the ForCES
in the IETF defines the architecture and protocol for separation of architecture that embodies the ForCES protocol and
Control Elements(CE) and Forwarding Elements(FE) in Network the state transfer mechanisms as defined in
Elements(NE) such as routers. [RFC3654] and [RFC3746] respectively [RFC5810].
define architectural and protocol requirements for the communication
between CE and FE. The ForCES protocol layer specification
[I-D.ietf-forces-protocol] describes the protocol semantics and
workings. The ForCES protocol layer operates on top of an inter-
connect hiding layer known as the TML. The relationship is
illustrated in Figure 1.
This document defines the SCTP based TML for the ForCES protocol ForCES TML: ForCES Protocol Transport Mapping Layer. A layer
layer. It also addresses all the requirements for the TML including in the ForCES protocol architecture that
security, reliability, etc as defined in [I-D.ietf-forces-protocol]. specifically addresses the protocol message
transportation issues, such as how the protocol
messages are mapped to different transport media
(like SCTP, IP, TCP, UDP, ATM, Ethernet, etc.), and
how to achieve and implement reliability, security,
etc.
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 There is some content overlap between the ForCES protocol
specification [I-D.ietf-forces-protocol] and this section (Section 3) specification [RFC5810] and this section (Section 3) in order to
in order to provide basic context to the reader of this document. provide basic context to the reader of this document.
The ForCES protocol layering constitutes two pieces: the PL and TML. The ForCES protocol layering constitutes two pieces, the PL and TML.
This is depicted in Figure 1. This is depicted in Figure 1.
+----------------------------------------------+ +----------------------------------------------+
| CE PL | | CE PL |
+----------------------------------------------+ +----------------------------------------------+
| CE TML | | CE TML |
+----------------------------------------------+ +----------------------------------------------+
^ ^
| |
ForCES PL |messages ForCES PL |messages
| |
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
association to Establish an NE Association
The PL 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 [I-D.ietf-forces-protocol]. The TML is message layout are defined in [RFC5810]. The TML is necessary to
necessary to connect two ForCES end-points as shown in Figure 1. connect two ForCES endpoints 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 nodes (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 from a ForCES end-point, the PL delivers its When transmitting from a ForCES endpoint, the PL delivers its
messages to the TML. The TML then delivers the PL message to the messages to the TML. The TML then delivers the PL message to the
destination TML(s). 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 (as described in the ForCES header). destination PL (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 [I-D.ietf-forces-protocol]. The PL is responsible for by the IETF [RFC5810]. The PL is responsible for associating an FE
associating an FE or CE to an NE. It is also responsible for tearing or CE to an NE. It is also responsible for tearing down such
down such associations. associations.
An FE may use the PL to asynchronously send packets to the CE. The An FE may use the PL to asynchronously send packets to the CE. The
FE may redirect via the PL (from outside the NE) various control FE may redirect various control protocol packets (e.g., OSPF, etc.)
protocol packets (e.g. OSPF, etc) to the CE. Additionally, the FE to the CE via the PL (from outside the NE). Additionally, the FE
delivers various events that CE has subscribed-to via PL delivers various events that the CE has subscribed to via the PL
[I-D.ietf-forces-model]. [RFC5812].
The CE and FE may interact synchronously via the PL. The CE issues 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 status requests to the FE and receives responses via the PL. The CE
also configures the associated FE's LFBs' components using the PL also configures the components of the associated FE's LFBs using the
[I-D.ietf-forces-model]. PL [RFC5812].
3.2. The TML 3.2. The TML
The TML is responsible for transport of the PL messages. The TML is responsible for the transport of the PL messages.
[I-D.ietf-forces-protocol] section 5 defines the requirements that [RFC5810], Section 5 defines the requirements that need to be met by
need to be met by a TML specification. The SCTP TML specified in a TML specification. The SCTP TML specified in this document meets
this document meets all the requirements specified in all the requirements specified in [RFC5810], Section 5.
[I-D.ietf-forces-protocol] section 5. Section 4.2.2 describes how Section 4.2.2 of this document describes how the TML requirements are
the TML requirements are met. met.
3.2.1. TML and PL Interfaces 3.2.1. TML and PL Interfaces
There are two interfaces to the PL and TML. The specification of There are two interfaces to the PL and TML. The specification of
these interfaces is out of scope for this document, but the these interfaces is out of scope for this document, but the
interfaces are introduced to show how they fit into the architecture interfaces are introduced to show how they fit into the architecture
and summarize the function provided at the interfaces. The first and summarize the function provided at the interfaces. The first
interface is between the PL and TML and the other is the CE Manager interface is between the PL and TML and the other is the CE Manager
(CEM)/FE Manager (FEM)[RFC3746] interface to both the PL and TML. (CEM)/FE Manager (FEM) [RFC3746] interface to both the PL and TML.
Both interfaces are shown in Figure 2. Both interfaces are shown in Figure 2.
+----------------------------+ +----------------------------+
| +----------------------+ | | +----------------------+ |
| | | | | | | |
+---------+ | | PL | | +---------+ | | PL | |
| | | +----------------------+ | | | | +----------------------+ |
|FEM/CEM |<---->| ^ | |FEM/CEM |<---->| ^ |
| | | | | | | | | |
+---------+ | |TML API | +---------+ | |TML API |
| | | | | |
| V | | V |
| +----------------------+ | | +----------------------+ |
| | | | | | | |
| | TML | | | | TML | |
| | | | | | | |
| +----------------------+ | | +----------------------+ |
+----------------------------+ +----------------------------+
Figure 2: The TML-PL interface Figure 2: The TML-PL Interface
The CEM/FEM[RFC3746] interface is responsible for bootstrapping and The CEM/FEM [RFC3746] interface is responsible for bootstrapping and
parameterization of the TML. In its most basic form the CEM/FEM 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 interface takes the form of a simple static config file that is read
on startup in the pre-association phase. on startup in the pre-association phase.
Appendix B discusses in more details the service interfaces. Appendix B discusses the service interfaces in more detail.
3.2.2. 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/SCTP then parameters such as SCTP ports and IP addresses need IP/SCTP, then parameters such as SCTP ports and IP 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 Quality of Service (QoS) Policy (or
Policy) Congestion Control Policy)
4. SCTP TML overview 4. SCTP TML Overview
SCTP [RFC4960] 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 can also
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 (e.g. 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 three transport
protocols mentioned above provide that we found attractive. These protocols mentioned above provide that we found attractive. These
include: include:
o Multi-homing o Multi-homing
o Runtime IP address binding o Runtime IP address binding
o A range of reliability shades with congestion control o A range of reliability shades with congestion control
o Built-in heartbeats o Built-in heartbeats
skipping to change at page 8, line 45 skipping to change at page 7, line 45
o Multi-streaming o Multi-streaming
o Message boundaries with reliability o Message boundaries with reliability
o Improved SYN DOS protection o Improved SYN DOS protection
o Simpler transport events o Simpler transport events
o Simplified replicasting o Simplified replicasting
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 in order to satisfy the TML requirements multiple transport protocols in order to satisfy the TML requirements
([I-D.ietf-forces-protocol] section 5). As a result it allows for ([RFC5810], Section 5). As a result, it allows for simpler coding
simpler coding and therefore reduces a lot of the interoperability and therefore reduces a lot of the interoperability concerns.
concerns.
SCTP is also very mature and widely used, making it a good choice for SCTP is also very mature and widely used, making it a good choice for
ubiquitous deployment. ubiquitous deployment.
4.2. Meeting TML requirements 4.2. Meeting TML Requirements
PL PL
+----------------------+ +----------------------+
| | | |
+-----------+----------+ +-----------+----------+
| TML API | TML API
TML | TML |
+-----------+----------+ +-----------+----------+
| | | | | |
| +------+------+ | | +------+------+ |
skipping to change at page 9, line 35 skipping to change at page 8, line 35
| +-+----+----+-+ | | +-+----+----+-+ |
| | SCTP | | | | SCTP | |
| +------+------+ | | +------+------+ |
| | | | | |
| | | | | |
| +------+------+ | | +------+------+ |
| | 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 northbound interface to the PL (utilizing the TML API). On the
south-bound interface, the TML core interfaces to the SCTP layer southbound interface, the TML core interfaces to the SCTP layer
utilizing the standard socket interface[I-D.ietf-tsvwg-sctpsocket]. utilizing the standard socket interface [TSVWG-SCTPSOCKET]. There
There are three SCTP socket connections opened between any two PL are three SCTP socket connections opened between any two PL endpoints
endpoints (whether FE or CE). (whether 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 10, line 33 skipping to change at page 9, line 33
High prio,| | | High prio,| | |
reliable | | | reliable | | |
channel | | | channel | | |
Y Y Y Y Y Y
+-+--------+--------+-+ +-+--------+--------+-+
| | | |
| SCTP | | SCTP |
| | | |
+---------------------+ +---------------------+
Figure 4: The TML-SCTP channels Figure 4: The TML-SCTP Channels
Figure 4 details further the interfacing between the TML core and Figure 4 details further the interfacing between the TML core and
SCTP layers. There are 3 channels used to group and prioritize the SCTP layers. There are three channels used to group and prioritize
work for different types of ForCES traffic. Each channel constitutes the work for different types of ForCES traffic. Each channel
an SCTP socket interface which has different properties. It should constitutes an SCTP socket interface that has different properties.
be noted that all SCTP channels are congestion aware (and for that It should be noted that all SCTP channels are congestion aware (and
reason that detail is left out of the description of the 3 channels). for that reason that detail is left out of the description of the
SCTP port 6704, 6705, 6706 are used for the higher, medium and lower three channels). SCTP ports 6704, 6705, and 6706 are used for the
priority channels respectively. SCTP Payload Protocol ID (PPID) higher-, medium-, and lower-priority channels, respectively. SCTP
values of 21, 22, and 23 are used for the higher, medium and lower Payload Protocol ID (PPID) values of 21, 22, and 23 are used for the
priority channels respectively. higher-, medium-, and lower-priority channels, respectively.
4.2.1.1. Justifying Choice of 3 Sockets 4.2.1.1. Justifying Choice of Three Sockets
SCTP allows up to 64K streams to be sent over a single socket SCTP allows up to 64 K 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 an indeterminate period of delivery) under congestion situations for an indeterminate period of
time (depending on how many outstanding lower priority packets are time (depending on how many outstanding lower-priority packets are
pending). For this reason, we elected to go with mapping each of the pending). For this reason, we elected to go with mapping each of the
three channels to a different SCTP socket (instead of a different three channels to a different SCTP socket (instead of a different
stream within a single socket). 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 6704. SCTP PPID 21 is used for all messages on the HP on port 6704. SCTP PPID 21 is used for all messages on the HP
channel. The HP channel is used for CE solicited messages and their channel. The HP channel 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.
PL priorities 4-7 MUST be used for all PL messages using this PL priorities 4-7 MUST be used for all PL messages using this
channel. The following PL messages MUST use the HP channel for channel. The following PL messages MUST use the HP channel for
transport: transport:
o Association Setup (default priority: 7) o AssociationSetup (default priority: 7)
o Association Setup Response (default priority: 7) o AssociationSetupResponse (default priority: 7)
o Association Teardown (default priority: 7) o AssociationTeardown (default priority: 7)
o Config (default priority: 4) o Config (default priority: 4)
o Config Response (default priority: 4) o ConfigResponse (default priority: 4)
o Query (default priority: 4) o Query (default priority: 4)
o Query Response (default priority: 4) o QueryResponse (default priority: 4)
If PL priorities outside of the specified range (4-7) priority, PPID If PL priorities outside of the specified range priority (4-7), PPID,
or PL message types other than the above are received on the HP or PL message types other than the above are received on the HP
channel, then the PL message MUST be dropped. channel, then the PL message MUST be dropped.
Although an implementation may choose different values from the Although an implementation may choose different values from the
defined range (4-7), it is RECOMMENDED that default priorities be defined range (4-7), it is RECOMMENDED that default priorities be
used. A response to a ForCES message MUST contain the same priority used. A response to a ForCES message MUST contain the same priority
as the request. Example, a config sent by the CE with priority 5 as the request. For example, a config sent by the CE with priority 5
MUST have a config-response from the FE with priority 5. MUST have a config-response from the FE with priority 5.
4.2.1.3. Medium Priority, Semi-Reliable channel 4.2.1.3. Medium-Priority, Semi-Reliable Channel
The medium priority (MP) channel uses SCTP-PR on port 6705. SCTP The medium-priority (MP) channel uses SCTP-PR on port 6705. SCTP
PPID 22 MUST be used for all messages on the MP channel. Time limits PPID 22 MUST be used for all messages on the MP channel. Time limits
on how long a message is valid are set on each outgoing message. 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 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 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 that carries the value of a counter that is
monotonically incrementing fits to use this channel. monotonically incrementing is fit to use this channel.
PL priority 3 MUST be used for PL messages on this channel. The PL priority 3 MUST be used for PL messages on this channel. The
following PL messages MUST use the MP channel for transport: following PL messages MUST use the MP channel for transport:
o Event Notification (default priority: 3) o Event Notification (default priority: 3)
If PL priority outside of the specified priority, PPID or PL message If PL priorities outside of the specified priority, PPID, or PL
type other than the above are received on the MP channel, then the PL message type other than the above are received on the MP channel,
message MUST be dropped. then the PL message MUST be dropped.
4.2.1.4. Lower Priority, Unreliable channel 4.2.1.4. Lower-Priority, Unreliable Channel
The lower priority (LP) channel uses SCTP port 6706. SCTP PPID 23 is The lower-priority (LP) channel uses SCTP port 6706. SCTP PPID 23 is
used for all messages on the LP channel. The LP channel also MUST used for all messages on the LP channel. The LP channel also MUST
use SCTP-PR with lower timeout values than the MP channel. The use 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
protocol's operations. For example: protocol's 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 that could be harmful. So any end-to-end retransmits will happen
happen from remote. remotely.
2. Some control protocols may desire to have obsolescence of 2. Some control protocols may desire having obsolescence of messages
messages over retransmissions; making this channel reliable over retransmissions; making this channel reliable contradicts
contradicts that desire. that desire.
Given ForCES PL heartbeats are traffic sensitive, sending them over Given ForCES PL heartbeats are traffic sensitive, sending them over
the LP channel also makes sense. If the other end is not processing 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 other channels, it will eventually get heartbeats; and if it is busy
processing other channels heartbeats will be obsoleted locally over processing other channels, heartbeats will be obsoleted locally over
time (and it does not matter if they did not make it). time (and it does not matter if they did not make it).
PL priorities 1-2 MUST be used for PL messages on this channel. PL PL priorities 1-2 MUST be used for PL messages on this channel. PL
messages that MUST use the MP channel for transport are: messages that MUST use the MP channel for transport are:
o Packet Redirect (default priority: 2) o PacketRedirect (default priority: 2)
o Heartbeats (default priority: 1) o Heartbeat (default priority: 1)
If PL priorities outside of the specified priority range, PPID or PL If PL priorities outside of the specified priority range, PPID, or PL
message types other than the above are received on the LP channel, message types other than the above are received on the LP channel,
then the PL message MUST be dropped. then the PL message MUST be dropped.
4.2.1.5. Scheduling of The 3 Channels 4.2.1.5. Scheduling of the Three Channels
Strict priority work-conserving scheduling is used to process both on In processing the sending and receiving of the PL messages, the TML
sending and receiving (of the PL messages) by the TML Core as shown core uses strict priority work-conserving scheduling, as shown in
in Figure 5. Figure 5.
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 channels there are no more left. The LP channel is processed only if channels
that are a higher priority than itself has no more messages left to that are a higher priority than itself have no messages left to
process. This means that under congestion situation, a higher process. This means that under a 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 processing prioritization The design intent of the SCTP TML is to tie processing
as described in Section 4.2.1.1 and transport congestion control to prioritization, as described in Section 4.2.1.1, and transport
provide implicit node congestion control. This is further detailed congestion control to provide implicit node congestion control. This
in Appendix A.2. is further detailed in Appendix A.2.
It should be emphasized that the work scheduling prioritization It should be emphasized that the work scheduling prioritization
scheme prescribed in this document is receiver based processing. scheme prescribed in this document is receiver-based processing.
Fully arrived packets on any of the channels are a source of work Fully arrived packets on any of the channels are a source of work
whose output may result in transmitted packets. However, we have no whose output may result in transmitted packets. However, we have no
control on the order in which SCTP/OS/network chooses to send control on the order in which the SCTP/OS/network chooses to send
transmitted packets across and make them available to the receiver. transmitted packets across and make them available to the receiver.
This is a limitation that we try to ameliorate by our choice of This is a limitation that we try to ameliorate by our choice of
channel properties, ForCES message grouping and the tying of CE and channel properties, ForCES message grouping, and the tying of CE and
FE work scheduling. And while that helps us ameliorate some of these FE work scheduling. While that helps us ameliorate some of these
issues it does not fully resolve all. issues, it does not fully resolve all.
From a ForCES perspective, we can tolerate some reordering. Example: From a ForCES perspective, we can tolerate some reordering. For
If an FE transmits a config response (HP), followed by 10000 OSPF example, if an FE transmits a config response (HP) followed by 10000
redirect packets(LP) and the CE gets 5 OSPF redirects (LP) first OSPF redirect packets (LP) and the CE gets 5 OSPF redirects (LP)
before the config response(HP), that is tolerable. What matters is first before the config response (HP), that is tolerable. What
the CE gets to processing the HP message soon (instead of sitting in matters is the CE gets to processing the HP message soon (instead of
long periods of time processing OSPF packets which would have sitting in long periods of time processing OSPF packets that would
happened if we use a single socket with 3 streams). This is have happened if we use a single socket with three streams). This is
particularly important in order to deal well with node overload as particularly important in order to deal with node overload well, as
discussed in Section 4.2.2.6. discussed in Section 4.2.2.6.
SCTP channel +----------+ SCTP channel +----------+
Work available | DONE +---<--<--+ Work available | DONE +---<--<--+
| +---+------+ | | +---+------+ |
Y ^ Y ^
| +-->--+ +-->---+ | | +-->--+ +-->---+ |
+-->-->-+ | | | | | +-->-->-+ | | | | |
| | | | | | ^ | | | | | | ^
| ^ ^ Y ^ Y | | ^ ^ v ^ v |
^ / \ | | | | | ^ / \ | | | | |
| / \ | ^ | ^ ^ | / \ | ^ | ^ ^
| / Is \ | / \ | / \ | | / Is \ | / \ | / \ |
| / there \ | /Is \ | /Is \ | | / there \ | /Is \ | /Is \ |
^ / HP work \ ^ /there\ ^ /there\ ^ ^ / HP work \ ^ /there\ ^ /there\ ^
| \ ? / | /MP work\ | /LP work\ | | \ ? / | /MP work\ | /LP work\ |
| \ / | \ ? / | \ ? / | | \ / | \ ? / | \ ? / |
| \ / | \ / | \ / ^ | \ / | \ / | \ / ^
| \ / ^ \ / ^ \ / | | \ / ^ \ / ^ \ / |
| \ / | \ / | \ / | | \ / | \ / | \ / |
^ Y-->-->-->+ Y-->-->-->+ Y->->->-+ ^ Y-->-->-->+ Y-->-->-->+ Y->->->-+
| | NO | NO | NO | | NO | NO | NO
| | | | | | | |
| Y Y Y | Y Y Y
| | YES | YES | YES | | YES | YES | YES
^ | | | ^ | | |
| Y Y Y | Y Y Y
| +----+------+ +---|-------+ +----|------+ | +----+------+ +---|-------+ +----|------+
| |- process | |- process | |- process | | |- process | |- process | |- process |
| | HP work | | MP work | | LP work | | | HP work | | MP work | | LP work |
| +------+----+ +-----+-----+ +-----+-----+ | +------+----+ +-----+-----+ +-----+-----+
| | | | | | | |
^ Y Y Y ^ Y Y Y
| | | | | | | |
| Y Y Y | Y Y Y
+--<--<---+--<--<----<----+-----<---<-----+ +--<--<---+--<--<----<----+-----<---<-----+
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(es) or a resolvable DNS/hostname(s) of the CE/FE. 1. The IP address(es) or a resolvable DNS/hostname(s) of the CE/FE.
2. Whether to use IPsec or not. If IPsec is used, how to 2. Whether or not to use IPsec. If IPsec is used, how to
parameterize the different required ciphers, keys etc as parameterize the different required ciphers, keys, etc., as
described in Section 7.1 described in Section 7.1
3. The HP SCTP port, as discussed in Section 4.2.1.2. The default 3. The HP SCTP port, as discussed in Section 4.2.1.2. The default
HP port value is 6704 (Section 6). HP port value is 6704 (Section 6).
4. The MP SCTP port, as discussed in Section 4.2.1.3. The default 4. The MP SCTP port, as discussed in Section 4.2.1.3. The default
MP port value is 6705 (Section 6). MP port value is 6705 (Section 6).
5. The LP SCTP port, as discussed in Section 4.2.1.4. The default 5. The LP SCTP port, as discussed in Section 4.2.1.4. The default
LP port value is 6706 (Section 6). LP port value is 6706 (Section 6).
4.2.2. Satisfying TML Requirements 4.2.2. Satisfying TML Requirements
[I-D.ietf-forces-protocol] section 5 lists requirements that a TML [RFC5810], Section 5 lists requirements that a TML needs to meet.
needs to meet. This section describes how the SCTP TML satisfies This section describes how the SCTP TML satisfies those requirements.
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.
4.2.2.2. 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.2.3. Satisfying Timeliness and Prioritization Requirement 4.2.2.3. Satisfying Timeliness and Prioritization Requirement
By using 3 sockets in conjunction with the partial-reliability By using three sockets in conjunction with the partial-reliability
feature[RFC3758], both timeliness and prioritization requirements are feature [RFC3758], both timeliness and prioritization requirements
addressed. are addressed.
4.2.2.4. Satisfying Addressing Requirement 4.2.2.4. Satisfying Addressing Requirement
There are no extra headers required for SCTP to fulfil this There are no extra headers required for SCTP to fulfill this
requirement. SCTP can be told to replicast packets to multiple requirement. SCTP can be told to replicast packets to multiple
destinations. The TML implementation will need to translate PL destinations. The TML implementation will need to translate PL
addresses, to a variety of unicast IP addresses in order to emulate addresses to a variety of unicast IP addresses in order to emulate
multicast and broadcast PL addresses. multicast and broadcast PL addresses.
4.2.2.5. Satisfying High Availability Requirement 4.2.2.5. Satisfying High-Availability Requirement
Transport link resiliency is one of SCTP's strongest point. Failure Transport link resiliency is one of SCTP's strongest points. Failure
detection and recovery is built in, as mentioned earlier. detection and recovery 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 others
other(s) are used without needing lower layer convergence are used without needing lower-layer convergence (routing, for
(routing, for example) or even the TML becoming aware. 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
peer IP address to detect reachability faults. The faults could per-peer IP address to detect reachability faults. The faults
be a result of an unreachable address or peer, which may be caused could be a result of an unreachable address or peer, which may be
by a variety of reasons, like interface, network, or endpoint caused by a variety of reasons, like interface, network, or
failures. The cause of the fault is noted. endpoint 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 Virtual Router
use. This feature is used in addition to multi-homing in a Redundancy Protocol (VRRP) [RFC5798] use. This feature is used in
planned migration of activity from one FE/CE to another. In such addition to multi-homing in a planned migration of activity from
a case, part of the provisioning recipe at the CE for replacing an one FE/CE to another. In such a case, part of the provisioning
FE involves migrating activity of one FE to another. recipe at the CE for replacing an FE involves migrating activity
of one FE to another.
4.2.2.6. Satisfying Node Overload Prevention Requirement 4.2.2.6. Satisfying Node Overload Prevention Requirement
The architecture of this TML defines three separate channels, one per The architecture of this TML defines three separate channels, one per
socket, to be used within any FE-CE setup. The work scheduling socket, to be used within any FE-CE setup. The work scheduling
design for processing the TML channels (Section 4.2.1.5) is strict design for processing the TML channels (Section 4.2.1.5) is a strict
priority. A fundamental desire of the strict prioritization is to priority. A fundamental desire of the strict prioritization is to
ensure that more important processing work always gets node resources ensure that more important processing work always gets node resources
over lesser important work. over less important work.
When a ForCES node CPU is overwhelmed because the incoming packet When a ForCES node CPU is overwhelmed because the incoming packet
rate is higher than it can keep up with, the channel queues grow and rate is higher than it can keep up with, the channel queues grow and
transport congestion subsequently follows. By virtue of using SCTP, transport congestion subsequently follows. By virtue of using SCTP,
the congestion is propagated back to the source of the incoming the congestion is propagated back to the source of the incoming
packets and eventually alleviated. packets and eventually alleviated.
The HP channel work gets prioritized at the expense of the MP which The HP channel work gets prioritized at the expense of the MP, which
gets prioritized over LP channels. The preferential scheduling only gets prioritized over LP channels. The preferential scheduling only
kicks in when there is node overload regardless of whether there is kicks in when there is node overload regardless of whether there is
transport congestion. As a result of the preferential work transport congestion. As a result of the preferential work
treatment, the ForCES node achieves a robust steady processing treatment, the ForCES node achieves a robust steady processing
capacity. Refer to Appendix A.2 for details on scheduling. capacity. Refer to Appendix A.2 for details on scheduling.
For an example of how the overload prevention works: consider a For an example of how the overload prevention works, consider a
scenario where an overwhelming amount redirected packets (from scenario where an overwhelming amount of redirected packets (from
outside the NE) coming into the NE may overload the FE while it has 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 outstanding config work from the CE. In such a case, the FE, while
it is busy processing config requests from the CE essentially ignores it is busy processing config requests from the CE, essentially
processing the redirect packets on the LP channel. If enough ignores processing the redirect packets on the LP channel. If enough
redirect packets accumulate, they are dropped either because the LP redirect packets accumulate, they are dropped either because the LP
channel threshold is exceeded or because they are obsoleted. If on channel threshold is exceeded or because they are obsoleted. If on
the other hand, the FE has successfully processed the higher priority the other hand, the FE has successfully processed the higher-priority
channels and their related work, then it can proceed and process the channels and their related work, then it can proceed and process the
LP channel. So as demonstrated in this case, the TML ties transport LP channel. So as demonstrated in this case, the TML ties transport
congestion and node overload implicitly together. congestion and node overload implicitly together.
4.2.2.7. Satisfying Encapsulation Requirement 4.2.2.7. Satisfying Encapsulation Requirement
The SCTP TML sets SCTP PPIDs to identify channels used as described The SCTP TML sets SCTP PPIDs to identify channels used as described
in Section 4.2.1.1. in Section 4.2.1.1.
5. SCTP TML Channel Work 5. SCTP TML Channel Work
skipping to change at page 17, line 35 skipping to change at page 16, line 27
There are two levels of TML channel work within an NE when a ForCES 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: 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 1. NE-level I/O work where a ForCES node (CE or FE) needs to choose
which of the peer nodes to process. which of the peer nodes to process.
2. Node-level I/O work where a ForCES node, handles the three SCTP 2. Node-level I/O work where a ForCES node, handles the three SCTP
TML channels separately for each single ForCES endpoint. TML channels separately for each single ForCES endpoint.
NE-level scheduling definition is left up to the implementation and NE-level scheduling definition is left up to the implementation and
is considered out of scope for this document. Appendix A.4 discuss is considered out of scope for this document. Appendix A.4 briefly
briefly some constraints that an implementer needs to worry about. discusses some constraints about which an implementer needs to worry.
This document provides suggestions on SCTP channel work This document provides suggestions on SCTP channel work
implementation in Appendix A. implementation in Appendix A.
The FE SHOULD do channel connections to the CE in the order of The FE SHOULD do channel connections to the CE in the order of
incrementing priorities i.e. LP socket first, followed by MP and incrementing priorities, i.e., LP socket first, followed by MP, and
ending with HP socket connection. The CE, however, MUST NOT assume ending with HP socket connection. The CE, however, MUST NOT assume
that there is ordering of socket connections from any FE. that there is ordering of socket connections from any FE.
6. IANA Considerations 6. IANA Considerations
Following the policies outlined in "Guidelines for Writing an IANA Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" [RFC5226], the following name spaces Considerations Section in RFCs" [RFC5226], the following namespaces
are defined in ForCES SCTP TML. are defined in ForCES SCTP TML.
o SCTP port 6704 for the HP channel, 6705 for the MP channel, and o SCTP port 6704 for the HP channel, 6705 for the MP channel, and
6706 for the LP channel. 6706 for the LP channel.
o SCTP Payload Protocol ID (PPID) 21 for the HP channel, 22 for the o SCTP Payload Protocol ID (PPID) 21 for the HP channel (ForCES-HP),
MP channel, and 23 for the LP channel. 22 for the MP channel (ForCES-MP), and 23 for the LP channel
(ForCES-LP).
XXX [Note to IANA]: Port allocations(SCTP 6700-6702) were made in
August 2009. We have been asked by IESG to change these as
prescribed above.
7. Security Considerations 7. Security Considerations
The SCTP TML provides the following security services to the PL: The SCTP TML provides the following security services to the PL:
o A mechanism to authenticate ForCES CEs and FEs at transport level o A mechanism to authenticate ForCES CEs and FEs at the transport
in order to prevent the participation of unauthorized CEs and level in order to prevent the participation of unauthorized CEs
unauthorized FEs in the control and data path processing of a and unauthorized FEs in the control and data path processing of a
ForCES NE. ForCES NE.
o A mechanism to ensure message authentication of PL data and o A mechanism to ensure message authentication of PL data and
headers transferred from the CE to FE (and vice-versa) in order to headers transferred from the CE to FE (and vice versa) in order to
prevent the injection of incorrect data into PL messages. prevent the injection of incorrect data into PL messages.
o A mechanism to ensure the confidentiality of PL data and headers o A mechanism to ensure the confidentiality of PL data and headers
transferred from the CE to FE (and vice-versa), in order to transferred from the CE to FE (and vice versa), in order to
prevent disclosure of PL information transported via the TML. prevent disclosure of PL information transported via the TML.
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.
IP Security Protocol (IPsec) [RFC4301] is used to provide needed IP Security Protocol (IPsec) [RFC4301] is used to provide needed
security mechanisms. security mechanisms.
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
[RFC5810]. Mutual authentication and key exchange protocol are
[I-D.ietf-forces-protocol]. Mutual authentication and key exchange provided by Internet Key Exchange (IKE) [RFC2409].
protocol are provided by Internet Key Exchange (IKE)[RFC2409].
7.1. IPsec Usage 7.1. IPsec Usage
A ForCES FE or CE MUST support the following: A ForCES FE or CE MUST support the following:
o Internet Key Exchange (IKE)[RFC2409] with certificates for o Internet Key Exchange (IKE)[RFC2409] with certificates for
endpoint authentication. endpoint authentication.
o Transport Mode Encapsulating Security Payload (ESP)[RFC4303]. 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.
o Replay protection[RFC4301]. o Replay protection [RFC4301].
A compliant implementation SHOULD provide operational means for A compliant implementation SHOULD provide operational means for
configuring the CE and FE to negotiate other cipher suites and even configuring the CE and FE to negotiate other cipher suites and even
use manual keying. use manual keying.
7.1.1. SAD and SPD setup 7.1.1. SAD and SPD Setup
To minimize the operational configuration it is RECOMMENDED that only To minimize the operational configuration, it is RECOMMENDED that
the IANA issued SCTP protocol number(132) be used as a selector in only the IANA-issued SCTP protocol number (132) be used as a selector
the Security Policy Database (SPD) for ForCES. In such a case only a in the Security Policy Database (SPD) for ForCES. In such a case,
single SPD and SAD entry is needed. only a single SPD and SAD entry is needed.
Setup MAY alternatively extend the above policy so that it uses the 3 Setup MAY alternatively extend the above policy so that it uses the
SCTP TML port numbers as SPD selectors. But as noted above this three SCTP TML port numbers as SPD selectors. But as noted above,
choice will require increased number of SPD entries. this choice will require an increased number of SPD entries.
In scenarios where multiple IP addresses are used within a single In scenarios where multiple IP addresses are used within a single
association, and there is desire to configure different policies on a association, and there is desire to configure different policies on a
per IP address, then it is RECOMMENDED to follow [RFC3554] per-IP address, then following [RFC3554] is RECOMMENDED.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Joel Halpern, Michael Tuxen, Randy The authors would like to thank Joel Halpern, Michael Tuxen, Randy
Stewart, Evangelos Haleplidis, Chuanhuang Li, Lars Eggert, Avshalom Stewart, Evangelos Haleplidis, Chuanhuang Li, Lars Eggert, Avshalom
Houri, Adrian Farrel, Juergen Quittek, Magnus Westerlund, and Pasi Houri, Adrian Farrel, Juergen Quittek, Magnus Westerlund, and Pasi
Eronen for engaging us in discussions that have made this document Eronen for engaging us in discussions that have made this document
better. better.
Ross Callon was an excellent manager who persevered in providing us Ross Callon was an excellent manager who persevered in providing us
guidance and Joel Halpern was an excellent document shepherd without guidance and Joel Halpern was an excellent document shepherd without
whom this document would have taken longer to publish. whom this document would have taken longer to publish.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-forces-protocol] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Requirement Levels", BCP 14, RFC 2119, March 1997.
Khosravi, H., and W. Wang, "ForCES Protocol
Specification", draft-ietf-forces-protocol-22 (work in
progress), March 2009.
[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.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) with IPsec", RFC 3554, July 2003. Protocol (SCTP) with IPsec", RFC 3554, July 2003.
skipping to change at page 20, line 47 skipping to change at page 19, line 43
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
9.2. Informative References [RFC5810] Doria, A., Ed., Hadi Salim, J., Ed., HAAS, R., Ed.,
Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and
[I-D.ietf-forces-model] J. Halpern, "Forwarding and Control Element Separation
Halpern, J. and J. Salim, "ForCES Forwarding Element (ForCES) Protocol Specification", RFC 5810, March 2010.
Model", draft-ietf-forces-model-16 (work in progress),
October 2008.
[I-D.ietf-tsvwg-sctpsocket] 9.2. Informative References
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-20 (work in progress),
January 2010.
[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.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
RFC 3768, April 2004. Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[TSVWG-SCTPSOCKET]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Work in Progress,
March 2010.
Appendix A. Suggested SCTP TML Channel Work Implementation Appendix A. Suggested SCTP TML Channel Work Implementation
As mentioned in Section 5, there are two levels of TML channel work As mentioned in Section 5, there are two levels of TML channel work
within an NE when a ForCES node (CE or FE) is connected to multiple within an NE when a ForCES node (CE or FE) is connected to multiple
other ForCES nodes: other ForCES nodes:
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose 1. NE-level I/O work where a ForCES node (CE or FE) needs to choose
which of the peer nodes to process. which of the peer nodes to process.
2. Node-level I/O work where a ForCES node, handles the three SCTP 2. Node-level I/O work where a ForCES node, handles the three SCTP
TML channels separately for each single ForCES endpoint. TML channels separately for each single ForCES endpoint.
NE-level scheduling definition is left up to the implementation and NE-level scheduling definition is left up to the implementation and
is considered out of scope for this document. Appendix A.4 discusses is considered out of scope for this document. Appendix A.4 briefly
briefly some constraints that an implementer needs to worry about. discusses some constraints about which an implementer needs to worry.
This document and in particular Appendix A.1, Appendix A.2 and This document, and in particular Appendix A.1, Appendix A.2, and
Appendix A.3 discuss details of node-level I/O work. Appendix A.3 discuss details of node-level I/O work.
A.1. SCTP TML Channel Initialization A.1. SCTP TML Channel Initialization
As discussed in Section 5, it is recommended that the FE SHOULD do As discussed in Section 5, it is recommended that the FE SHOULD do
socket connections to the CE in the order of incrementing priorities socket connections to the CE in the order of incrementing priorities,
i.e. LP socket first, followed by MP and ending with HP socket i.e., LP socket first, followed by MP, and ending with HP socket
connection. The CE, however, MUST NOT assume that there is ordering connection. The CE, however, MUST NOT assume that there is ordering
of socket connections from any FE. Appendix B.1 has more details on of socket connections from any FE. Appendix B.1 has more details on
the expected initialization of SCTP channel work. the expected initialization of SCTP channel work.
A.2. Channel work scheduling A.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. It is left to the work quanta, etc.) not described in this document. It is left to the
implementer to take care of those details. implementer 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.
A.2.1. FE Channel work scheduling A.2.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 that creates ForCES work
work to be executed by the FE. to be executed by the FE.
2. ForCES events which result in transmission of unsolicited ForCES 2. ForCES events that result in transmission of unsolicited ForCES
packets to the CE via the MP channel. packets to the CE via the MP channel.
3. Incoming Redirect work in the form of control packets that come 3. Incoming Redirect work in the form of control packets that come
from the CE via LP channel. After redirect processing, these from the CE via LP channel. After redirect processing, these
packets get sent out on external (to the NE) interface. packets get sent out on external (to the NE) interface.
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. 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).
A.2.2. CE Channel work scheduling A.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. Transmit any outstanding HP work it needs the FE(s) to
to complete. complete.
2. Incoming ForCES events from the FE(s) via the MP channel. 2. Incoming ForCES events from the FE(s) via the MP channel.
3. Outgoing Redirect work in the form of control packets that get 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) sent from the CE via LP channel destined to external (to the NE)
interface on FE(s). interface on FE(s).
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 interfaces (to the NE) on the FE(s).
It is worth to repeat for emphasis again that the SCTP TML processes It is worth repeating, for emphasis, that the SCTP TML processes the
the channel work in strict priority. For example, if there are channel work in strict priority. For example, if there are messages
messages incoming from an FE on the HP channel, they will be incoming from an FE on the HP channel, they will be processed first
processed first until there are no more left before processing the until there are no more left before processing the next priority
next priority work which is to transmit any outstanding HP channel work, which is to transmit any outstanding HP channel messages going
messages going to the FE. to the FE.
A.3. SCTP TML Channel Termination A.3. SCTP TML Channel Termination
Appendix B.2 describes a controlled disassociation of the FE from the Appendix B.2 describes a controlled disassociation of the FE from the
NE. NE.
It is also possible for connectivity to be lost between the FE and CE 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 on one or more sockets. In cases where SCTP multi-homing features
are used for path availability, the disconnection of a socket will are used for path availability, the disconnection of a socket will
only occur if all paths are unreachable; otherwise, SCTP will ensure only occur if all paths are unreachable; otherwise, SCTP will ensure
reachability. In the situation of a total connectivity loss of even 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 one SCTP socket, it is recommended that the FE and CE SHOULD assume a
state equivalent to ForCES Association Teardown being issued and state equivalent to ForCES Association Teardown being issued and
follow the sequence described in Appendix B.2. follow the sequence described in Appendix B.2.
A CE could also disconnect sockets to an FE to indicate an "emergency A CE could also disconnect sockets to an FE to indicate an "emergency
teardown". The "emergency teardown" may be necessary in cases when a 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 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 a lot of outstanding commands (some of which the FE hasn't gotten
to processing yet). By virtue of the CE closing the connections, the around to processing, yet). By virtue of the CE closing the
FE will immediately be asynchronously notified and will not have to connections, the FE will immediately be asynchronously notified and
process any outstanding commands from the CE. will not have to process any outstanding commands from the CE.
A.4. SCTP TML NE level channel scheduling A.4. SCTP TML NE-Level Channel Scheduling
In handling NE-level I/O work, an implementation needs to worry about In handling NE-level I/O work, an implementation needs to worry about
being both fair and robust across peer ForCES nodes. being both fair and robust across peer ForCES nodes.
Fairness is desired so that each peer node makes progress across the 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; NE. For the sake of illustration, consider two FEs connected to a
whereas one FE has a few HP messages that need to be processed by the CE; whereas one FE has a few HP messages that need to be processed by
CE, another may have infinite HP messages. The scheduling scheme may the CE, another may have infinite HP messages. The scheduling scheme
decide to use a quota scheduling system to ensure that the second FE may decide to use a quota scheduling system to ensure that the second
does not hog the CE cycles. FE does not hog the CE cycles.
Robustness is desired so that the NE does not succumb to a DoS attack Robustness is desired so that the NE does not succumb to a Denial-of-
from hostile entities and always achieves a maximum stable workload Service (DoS) attack from hostile entities and always achieves a
processing level. For the sake of illustration consider again two maximum stable workload processing level. For the sake of
FEs connected to a CE. Consider FE1 as having a large number of HP illustration, consider again two FEs connected to a CE. Consider FE1
and MP messages and FE2 having a large number of MP and LP messages. as having a large number of HP and MP messages and FE2 having a large
The scheduling scheme needs to ensure that while FE1 always gets its number of MP and LP messages. The scheduling scheme needs to ensure
messages processed, at some point we allow FE2 messages to be that while FE1 always gets its messages processed, at some point we
processed. A promotion and preemption based scheduling could be used allow FE2 messages to be processed. A promotion and preemption-based
by the CE to resolve this issue. scheduling could be used by the CE to resolve this issue.
Appendix B. Suggested Service Interface Appendix B. Suggested Service Interface
This section outlines high level service interface between FEM/CEM This section outlines a 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 care of details and even follow a The implementer is expected to care of 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
successful TML bootstrap is that the CE TML and the FE TML successful TML bootstrap is that the CE TML and the FE TML
connect to each other at the transport level. connect to each other at the transport level.
2. Transmission and reception of the PL messages commences after a 2. Transmission and reception of the PL messages commences after a
successful TML bootstrap. The PL uses send and receive PL-TML successful TML bootstrap. The PL uses send and receive PL-TML
interfaces to communicate to its peers. The TML is agnostic to interfaces to communicate to its peers. The TML is agnostic to
the nature of the messages being sent or received. The first the nature of the messages being sent or received. The first
message exchanges that happen are to establish ForCES message exchanges that happen are to establish ForCES
association. Subsequent messages maybe either unsolicited events association. Subsequent messages may be either unsolicited
from the FE PL, control message redirects from/to the CE to/from events from the FE PL, control message redirects to/from the CE
FE, and configuration from the CE to the FE and their responses to/from FE, or configuration from the CE to the FE, and their
flowing from the FE to the CE. responses flowing from the FE to the CE.
3. The PL does a shutdown of the TML after terminating ForCES 3. The PL does a shutdown of the TML after terminating ForCES
association. association.
B.1. TML Boot-strapping B.1. TML Bootstrapping
Figure 6 illustrates a flow for the TML bootstrapped by the PL. Figure 6 illustrates a flow for the TML bootstrapped by the PL.
When the PL starts up (possibly after some internal initialization), When the PL starts up (possibly after some internal initialization),
it boots up the TML. The TML first interacts with the FEM/CEM and 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 acquires the necessary TML parameterization (Section 4.2.1.6). Next,
the TML uses the information it retrieved from the FEM/CEM interface the TML uses the information it retrieved from the FEM/CEM interface
to initialize itself. to initialize itself.
The TML on the FE proceeds to connect the 3 channels to the CE. The The TML on the FE proceeds to connect the three channels to the CE.
socket interface is used for each of the channels. The TML continues The socket interface is used for each of the channels. The TML
to re-try the connections to the CE until all 3 channels are continues to re-try the connections to the CE until all three
connected. It is advisable that the number of connection retry channels are connected. It is advisable that the number of
attempts and the time between each retry is also configurable via the connection retry attempts and the time between each retry is also
FEM. On failure to connect one or more channels, and after the configurable via the FEM. On failure to connect one or more
configured number of retry thresholds is exceeded, the TML will channels, and after the configured number of retry thresholds is
return an appropriate failure indicator to the PL. On success (as exceeded, the TML will return an appropriate failure indicator to the
shown in Figure 6), a success indication is presented to the PL. PL. On success (as shown in Figure 6), a success indication is
presented to the PL.
FE PL FE TML FEM CEM CE TML CE PL FE PL FE TML FEM CEM CE TML CE PL
| | | | | | | | | | | |
| | | | | Bootup | | | | | | Bootup |
| | | | |<-------------------| | | | | |<-------------------|
| Bootup | | | | | | Bootup | | | | |
|----------->| | |get CEM info| | |----------->| | |get CEM info| |
| |get FEM info | |<-----------| | | |get FEM info | |<-----------| |
| |------------>| ~ ~ | | |------------>| ~ ~ |
| ~ ~ |----------->| | | ~ ~ |----------->| |
skipping to change at page 26, line 34 skipping to change at page 25, line 34
| ~ ~ - FE TML info init ~ | ~ ~ - FE TML info init ~
| | channels connected | | | | channels connected | |
| |<------------------------------| | | |<------------------------------| |
| Bootup | | | | Bootup | | |
| succeeded | | | | succeeded | | |
|<-----------| | | |<-----------| | |
| | | | | | | |
Figure 6: SCTP TML Bootstrapping Figure 6: SCTP TML Bootstrapping
On the CE things are slightly different. After initializing from the On the CE, things are slightly different. After initializing from
CEM, the TML on the CE side proceeds to initialize the 3 channels to the CEM, the TML on the CE side proceeds to initialize the three
listen to remote connections from the FEs. The success or failure channels to listen to remote connections from the FEs. The success
indication is passed on to the CE PL (in the same manner as was done or failure indication is passed on to the CE PL (in the same manner
in the FE). as was done in the FE).
Post boot-up, the CE TML waits for connections from the FEs. Upon a Post bootup, the CE TML waits for connections from the FEs. Upon a
successful connection by an FE, the CE TML level keeps track of the 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 details of the FE. Note, at this stage only
transport level connection has been established; ForCES level transport-level connection has been established; ForCES-level
association follows using send/receive PL-TML interfaces (refer to association follows using send/receive PL-TML interfaces (refer to
Appendix B.3 and Figure 8). Appendix B.3 and Figure 8).
B.2. TML Shutdown B.2. TML Shutdown
Figure 7 shows an example of an FE shutting down the TML. It is 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 assumed at this point that the ForCES Association Teardown has been
issued by the CE. It should also be noted that different issued by the CE. It should also be noted that different
implementations may have different procedures for cleaning up state implementations may have different procedures for cleaning up state,
etc. etc.
When the FE PL issues a shutdown to its TML for a specific PL ID, the 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 TML releases all the channel connections to the CE. This is achieved
by closing the sockets used to communicate to the CE. This results by closing the sockets used to communicate to the CE. This results
in the stack sending a SCTP shutdown which is received on the CE. in the stack sending a SCTP shutdown, which is received on the CE.
FE PL FE TML CE TML CE PL FE PL FE TML CE TML CE PL
| | | | | | | |
| Shutdown | | | | Shutdown | | |
|----------->| | | |----------->| | |
| |-disconnect 3 chans. | | | |-disconnect 3 chans. | |
| |-SCTP level shutdown | | | |-SCTP level shutdown | |
| |------------------------>| | | |------------------------>| |
| | | | | | | |
| | |TML detects shutdown| | | |TML detects shutdown|
skipping to change at page 27, line 35 skipping to change at page 26, line 41
| |- clean up any state of | | | |- clean up any state of | |
| |-channels disconnected | | | |-channels disconnected | |
| |<------------------------| | | |<------------------------| |
| |-SCTP shutdown ACK | | | |-SCTP shutdown ACK | |
| | | | | | | |
| Shutdown | | | | Shutdown | | |
| succeeded | | | | succeeded | | |
|<-----------| | | |<-----------| | |
| | | | | | | |
Figure 7: FE Shutting down Figure 7: FE Shutting Down
On the CE side, a TML disconnection would result in possible cleanup On the CE side, a TML disconnection would result in possible cleanup
of the FE state. Optionally, depending on the implementation, there of the FE state. Optionally, depending on the implementation, there
may be need to inform the PL about the TML disconnection. The CE may be need to inform the PL about the TML disconnection. The CE-
stack level SCTP sends an acknowledgement to the FE TML in response stack-level SCTP sends an acknowledgement to the FE TML in response
to the earlier SCTP shutdown. to the earlier SCTP shutdown.
B.3. TML Sending and Receiving B.3. TML Sending and Receiving
The TML should be agnostic to the content of the PL messages, or The TML should be agnostic to the content of the PL messages, or
their operations. The PL should provide enough information to the their operations. The PL should provide enough information to the
TML for it to assign an appropriate priority and loss behavior to the TML for it to assign an appropriate priority and loss behavior to the
message. Figure 8 shows an example of a message exchange originated message. Figure 8 shows an example of a message exchange originated
at the FE and sent to the CE (such as a ForCES association message) at the FE and sent to the CE (such as a ForCES association message),
which illustrates all the necessary service interfaces for sending which illustrates all the necessary service interfaces for sending
and receiving. and receiving.
When the FE PL sends a message to the TML, the TML is expected to 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. pick one of HP/MP/LP channels and send out the ForCES message.
FE PL FE TML CE TML CE PL FE PL FE TML CE TML CE PL
| | | | | | | |
|PL send | | | |PL send | | |
|----------->| | | |----------->| | |
skipping to change at page 28, line 40 skipping to change at page 27, line 47
| | |-TML send | | | |-TML send |
| |<-------------| | | |<-------------| |
| |-TML Receive | | | |-TML Receive | |
| |-mux to PL | | | |-mux to PL | |
| PL Recv | | | | PL Recv | | |
|<---------- | | | |<---------- | | |
| | | | | | | |
Figure 8: Send and Recv Flow Figure 8: Send and Recv Flow
When the CE TML receives the ForCES message on the channel it was When the CE TML receives the ForCES message on the channel on which
sent on, it demultiplexes the message to the CE PL. it was sent, it demultiplexes the message to the CE PL.
The CE PL, after some processing (in this example dealing with the 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 FE's association), sends the TML the response. As in the case of FE
of FE PL, the CE TML picks the channel to send on before sending. 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 The processing of the ForCES message upon arrival at the FE TML and
delivery to the FE PL is similar to the CE side equivalent as shown delivery to the FE PL is similar to the CE side equivalent as shown
above in Appendix B.3. above in Appendix B.3.
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
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
 End of changes. 155 change blocks. 
414 lines changed or deleted 404 lines changed or added

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