| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2009.
This document defines the SCTP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) [RFC2960] (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,” October 2000.) and also describes how this TML addresses all the requirements described in [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.) and the ForCES protocol [FE‑PROTO] (Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008.) draft.
1.
Definitions
2.
Introduction
3.
Protocol Framework Overview
3.1.
The PL
3.2.
The TML layer
3.2.1.
TML Parameterization
3.3.
The TML-PL interface
4.
SCTP TML overview
4.1.
Rationale for using SCTP for TML
4.2.
Meeting TML requirements
4.2.1.
SCTP TML Channels
4.2.2.
Satisfying Reliability Requirement
4.2.3.
Satisfying Congestion Control Requirement
4.2.4.
Satisfying Timeliness and prioritizationi Requirement
4.2.5.
Satisfying Addressing Requirement
4.2.6.
Satisfying HA Requirement
4.2.7.
Satisfying DOS Prevention Requirement
4.2.8.
Satisfying Encapsulation Requirement
5.
IANA Considerations
6.
Security Considerations
6.1.
TLS Usage for Securing TML
6.2.
IPSec Usage for securing TML
7.
Manageability Considerations
8.
Acknowledgements
9.
References
9.1.
Normative References
9.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The following definitions are taken from [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.)and [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.):
ForCES Protocol -- The protocol used at the Fp reference point in the ForCES Framework in [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.).
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol architecture that defines the ForCES protocol architecture and the state transfer mechanisms as defined in [FE‑PROTO] (Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008.).
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES protocol architecture that specifically addresses the protocol message transportation issues, such as how the protocol messages are mapped to different transport media (like TCP, IP, ATM, Ethernet, etc), and how to achieve and implement reliability, multicast, ordering, etc.
| TOC |
The ForCES (Forwarding and Control Element Separation) working group in the IETF is defining the architecture and protocol for separation of Control Elements(CE) and Forwarding Elements(FE) in Network Elements(NE) such as routers. [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.) and [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.) respectively define architectural and protocol requirements for the communication between CE and FE. The ForCES protocol layer specification [FE‑PROTO] (Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008.) 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 (Message exchange between CE and FE to establish an NE association).
This document defines the SCTP based TML for the ForCES protocol layer. It also addresses all the requirements for the TML including security, reliability, etc as defined in [FE‑PROTO] (Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008.).
XXXX: TBD - a reference to the correct document for a more complete list of terminology.
| TOC |
The reader is referred to the Framework document [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.), and in particular sections 3 and 4, for an architectural overview and explanation of where and how the ForCES protocol fits in.
There is some content overlap between the ForCES protocol draft [FE‑PROTO] (Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008.) and this section in order to provide clarity to the reader of this document.
The ForCES layout constitutes two pieces: the PL and TML layer.
This is depicted in Figure 1 (Message exchange between CE and FE to establish an NE association).
+----------------------------------------------+
| CE PL |
+----------------------------------------------+
| CE TML |
+----------------------------------------------+
^
|
ForCES | (i.e. Forces data + control
PL | packets )
messages |
over |
specific |
TML |
encapsulation|
and |
transport |
|
v
+-----------------------------------------------+
| FE TML |
+-----------------------------------------------+
| FE PL |
+-----------------------------------------------+
| Figure 1: Message exchange between CE and FE
to establish an NE association |
Both the PL and TML are standardized by the IETF. While only one PL is defined, different TMLs are expected to be standardized. The TML at each of the peers (CE and FE) is expected to be of the same definition in order to inter-operate.
When transmitting, the PL delivers its messages to the TML. The TML then delivers the PL message to the destination peer TML(s) as defined by the addressing in the PL message.
On reception of a message, the TML delivers the message to its destination PL layer(s) (as described in the ForCES header).
| TOC |
The PL is common to all implementations of ForCES and is standardized by the IETF [FE‑PROTO] (Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008.). The PL layer is responsible for associating an FE or CE to an NE. It is also responsible for tearing down such associations. An FE uses the PL layer to throw various subscribed-to events to the CE PL layer as well as respond to various status requests issued from the CE PL. The CE configures both the FE and associated LFBs attributes using the PL layer. In addition the CE may send various requests to the FE to activate or deactivate it, reconfigure its HA parameterization, subscribe to specific events etc.
| TOC |
The TML layer is responsible for transport of the PL layer messages. The TML provides the following services on behalf of the ForCES protocol:
It is expected more than one TML will be standardized. The different TMLs each could implement things differently based on capabilities of underlying media and transport. However, since each TML is standardized, interoperability is guaranteed only as long as both endpoints support the same TML.
| TOC |
It is expected that it should be possible to use a configuration reference point, such as the FEM or the CEM, to configure the TML.
Some of the configured parameters may include:
| TOC |
[TML‑API] (M. Wang, W., Hadi Salim, J., and A. Audu, “ForCES Transport Mapping Layer (TML) Service Primitives,” Feb. 2007.) defines an interface between the PL and the TML layers. The end goal of [TML‑API] (M. Wang, W., Hadi Salim, J., and A. Audu, “ForCES Transport Mapping Layer (TML) Service Primitives,” Feb. 2007.) is to provide a consistent top edge semantics for all TMLs to adhere to. Conforming to such an interface makes it easy to plug in different TMLs over time. It also allows for simplified TML parameterization requirement stated in Section 3.2.1 (TML Parameterization).
+----------------------+
| |
| PL Layer |
| |
+----------------------+
^
|
| TML API
|
|
V
+----------------------+
| |
| TML Layer |
| |
+----------------------+
| Figure 2: The TML-PL interface |
We are going to assume the existence of such an interface and not discuss it further. The reader is encouraged to read [TML‑API] (M. Wang, W., Hadi Salim, J., and A. Audu, “ForCES Transport Mapping Layer (TML) Service Primitives,” Feb. 2007.) as a background.
Editorial Note: There is some concern (and confusion) about defining APIs in ForCES. So at the moment the future of [TML‑API] (M. Wang, W., Hadi Salim, J., and A. Audu, “ForCES Transport Mapping Layer (TML) Service Primitives,” Feb. 2007.) is unknown (unless these concerns are cleared).
| TOC |
SCTP [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,” October 2000.) is an end-to-end transport protocol that is equivalent 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 do most of what a combination of the other transport protocols can achieve (eg TCP and DCCP or TCP and UDP).
Like TCP, it provides ordered, reliable, connection-oriented, flow-controlled, congestion controlled data exchange. Unlike TCP, it does not provide byte streaming and instead provides message boundaries.
Like UDP, it can provide unreliable, unordered data exchange. Unlike UDP, it does not provide multicast support
Like DCCP, it can provide unreliable, ordered, congestion controlled, connection-oriented data exchange.
SCTP also provides other services that none of the 3 transport protocols mentioned above provide. These include:
| TOC |
SCTP has all the features required to provide a robust TML. As a transport that is all-encompassing, it negates the need for having multiple transport protocols, as has been suggested so far in the other proposals for TMLs. As a result it allows for simpler coding and therefore reduces a lot of the interoperability concerns.
SCTP is also very mature and widely deployed completing the equation that makes it a superior choice in comparison with other proposed TMLs.
| TOC |
PL
+---------------------+
| |
+-----------+---------+
| TML API
TML |
+-----------+----------+
| | |
| +------+------+ |
| | TML core | |
| +-+----+----+-+ |
| | | | |
| SCTP socket API |
| | | | |
| | | | |
| +-+----+----+-+ |
| | SCTP | |
| +------+------+ |
| | |
| | |
| +------+------+ |
| | IP | |
| +-------------+ |
+----------------------+
| Figure 3: The TML-SCTP interface |
Figure 3 (The TML-SCTP interface) details the interfacing between the TML and SCTP and the internals of the SCTP TML. The core of the TML interfaces on its north bound interface to the PL (utilizing the TML API). On the southbound interface, the TML core interfaces to the SCTP layer utilizing the standard socket interface [Editorial: add here a reference to SCTP Sockets API doc]. There are three SCTP socket connections opened between any two PL layers (whether FE or CE).
| TOC |
+--------------------+
| |
| TML core |
| |
+-+-------+--------+-+
| | |
| Med prio, |
| Semi-reliable |
| channel |
| | Low prio,
| | Unreliable channel
| | |
^ ^ ^
| | |
Y Y Y
High prio,| | |
reliable | | |
channel | | |
Y Y Y
+-+--------+--------+-+
| |
| SCTP |
| |
+---------------------+
| Figure 4: The TML-SCTP channels |
Figure 4 (The TML-SCTP channels) details further the interfacing between the TML core and SCTP layers. There are 3 channels used to separate and prioritize the different types of ForCES traffic. Each channel constitutes a socket interface. It should be noted that all SCTP channels are congestion aware (and for that reason that detail is left out of the description of the 3 channels). SCTP port 6700, 6701, 6702 are used for the higher, medium and lower priority channels respectively.
| TOC |
SCTP allows upto 64K streams to be sent over a single socket interface. The authors initially envisioned using a single socket for all three channels (mapping a channel to an SCTP stream). This simplifies programming of the TML as well as conserves use of SCTP ports.
Further analysis revealed head of line blocking issues with this initial approach. Lower priority packets not needing reliable delivery could block higher priority packets (needing reliable delivery) under congestion situation. This proposal alleviates that problem by making the medium and low priority channels obsolete over a period of time, but that is still insufficient to resolve the outstanding HOL issue.
XXX: Talk here about Michael Tuxen's approach which will allow for SCTP to prioritize streams within a single socket. Unfortunately, until that approach completes standardization effort we cannot recomend its use for ForCES TML.
| TOC |
The higher priority channel uses a standard SCTP reliable socket on port 6700. It is used for CE solicited messages and their responses:
Some events which require guaranteed delivery could also optionally use this interface. An example of an event that would be prioritized and delivered on this channel would be a PL heartbeat (in a scenario when the first few HBs fail to make it to the destination).
| TOC |
The medium priority channel uses SCTP-PR on port 6701. Time limits on how long a message is valid are set on each outgoing message. This channel is used for events from the FE to the CE that are obsoleted over time. Events that are accumulative in nature and are recoverable by the CE (by issuing a query to the FE) can tolerate lost events and therefore should this channel. Example a counter that is monotonically incrementing fits to use this channel.
| TOC |
The lower priority channel on SCTP port 6702 is used for redirect messages between the CE and FE. This channel also uses SCTP-PR with lower timeout values than the medium priority channel. The reason an unreliable channel is used for redirect messages is to allow the control protocol at both the CE and its peer-endpoint to take charge of how the end to end semantics of the said control protocol's operations. For example:
| TOC |
Strict priority work-conserving scheduling is used to process both on sending and receving by the TML Core. This means that the higher priority messages are always processed first until there are no more left. The lower priority channel is processed only if a channel that is higher priority than itself has no more messages left to process. This means that under congestion situation, a higher priority channel with sufficient messages that occupy the available bandwidth would starve lower priority channel(s). The authors feel this is justified given the choice of the messaging prioritization as described above.
| TOC |
TBA: This section will have a list of all parameters needed for booting the TML.
| TOC |
TBA: This section will show how the FE and CE side of bootstrapping.
| TOC |
As mentioned earlier, a shade of reliability ranges is possible in SCTP. Therefore this requirement is met.
| TOC |
Congestion control is built into SCTP. Therefore, this requirement is met.
| TOC |
By using 3 sockects in conjunction with the partial-reliability feature, both timeliness and prioritization can be achieved.
| TOC |
SCTP can be told to replicast packets to multiple destinations. The TML will translate PL level addresses, to a variety of unicast IP addresses in order to emulate multicast and broadcast. Note, that there are no extra headers required for SCTP.
| TOC |
Transport link resiliency is SCTP's strongest point (where it totally outclasses all other TML proposals). Failure detection and recovery is built in as mentioned earlier.
| TOC |
Three separate streams (one per socket) are used within any FE-CE setup. The scheduling design for processing channels (Section 4.2.1.5 (Scheduling of The 3 Channels))is strict priority. This guarantees that lower priority messages are starved if lack of resources happen. i.e under congestion (which is likely to occur under DOS attack), redirected packets (from outside the NE) get very low priority and obsoleted in short periods if the CE-FE path is congested without consuming resources on the CE-FE path.
| TOC |
There is no extra encapsulation added by this TML. SCTP provides for extensions to be added to it by defining new chunks. In the future, should the need arise, a new SCTP extension can be defined to meet newer ForCES requirements.
| TOC |
This document makes request of IANA to reserve SCTP ports 6700, 6701, and 6702.
| TOC |
When operating under a secured environment then the network administrator can turn off all the security functions. This feature is configured during the pre-association phase of the protocol. This mode is called "no security" mode of operation.
When the CEs, FEs are running over IP networks or in an insecure environment, the operator has the choice of configuring either TLS [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) or IPSec [RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.) to provide needed security. For IPSec, The security association between the CEs and FEs MUST be established before any ForCES protocol messages are exchanged between the CEs and FEs.
| TOC |
This section is applicable for CE or FE endpoints that use the TML with TLS [RFC2246] (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) to secure communication.
Since CE is master and FEs are slaves, the FEs are TLS clients and CEs are TLS server. The endpoints that implement TLS MUST perform mutual authentication during TLS session establishment process. CE must request certificate from FE and FE needs to pass the requested information.
We recommend TLS-RSA-with-AES-128-CBC-SHA cipher suite. Although consistency is expected it is possible for the CE or FE to negotiate other TLS cipher suites.
| TOC |
This section is applicable for CE or FE endpoints that use the TML with IPSec [RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.) to secure their respective communication. IPSec is transparent to the higher-layer applications and can provide security for any transport layer protocol. This mechanism is can be used to secure just the control or both the control and the data channel simultaneously.
Editorial Note: We need to flesh the security section with more details.
| TOC |
TBA
| TOC |
The authors would like to thank Joel Halpern, Michael Tuxen and Randy Stewart for engaging us in discussions that have made this draft better.
| TOC |
| TOC |
| [RFC2246] | Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” RFC 2246, January 1999 (TXT). |
| [RFC2401] | Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401, November 1998 (TXT, HTML, XML). |
| [RFC2434] | Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML). |
| [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 (TXT). |
| [RFC3654] | Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” RFC 3654, November 2003 (TXT). |
| [RFC3746] | Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” RFC 3746, April 2004 (TXT). |
| TOC |
| [FE-MODEL] | Halpern, J., Deleganes, E., and J. Hadi Salim, “ForCES Forwarding Element Model,” February 2008. |
| [FE-PROTO] | Doria (Ed.), A., Haas (Ed.), R., Hadi Salim (Ed.), J., Khosravi (Ed.), H., M. Wang (Ed.), W., Dong, L., and R. Gopal, “ForCES Protocol Specification,” March 2008. |
| [TML-API] | M. Wang, W., Hadi Salim, J., and A. Audu, “ForCES Transport Mapping Layer (TML) Service Primitives,” Feb. 2007. |
| TOC |
| Jamal Hadi Salim | |
| ZNYX Networks | |
| Ottawa, Ontario | |
| Canada | |
| Email: | hadi@znyx.com |
| Kentaro Ogawa | |
| NTT Corporation | |
| 3-9-11 Midori-cho | |
| Musashino-shi, Tokyo 180-8585 | |
| Japan | |
| Email: | ogawa.kentaro@lab.ntt.co.jp |
| TOC |
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.