draft-ietf-forces-sctptml-03.txt   draft-ietf-forces-sctptml-04.txt 
Network Working Group J. Hadi Salim Network Working Group J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Expires: December 6, 2009 K. Ogawa Expires: January 2, 2010 K. Ogawa
NTT Corporation NTT Corporation
June 4, 2009 July 1, 2009
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP based TML (Transport Mapping Layer) for ForCES protocol
draft-ietf-forces-sctptml-03 draft-ietf-forces-sctptml-04
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 6, 2009. This Internet-Draft will expire on January 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3
3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5
3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8
4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 8 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 8
4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 9 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 9
4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14 4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14
5. SCTP TML Channel work . . . . . . . . . . . . . . . . . . . . 16 5. SCTP TML Channel Work . . . . . . . . . . . . . . . . . . . . 16
5.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5.2. Channel work scheduling . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 17 7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 17 7.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 18
5.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Service Interface . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
6.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. SCTP TML Channel Work Implementation . . . . . . . . 19
6.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 21 A.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 A.2. Channel work scheduling . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 20
8.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 24 A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 21
8.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 24 A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Service Interface . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 25 B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 24
B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Definitions 1. Definitions
The following definitions are taken from [RFC3654]and [RFC3746]: The following definitions are taken from [RFC3654]and [RFC3746]:
ForCES Protocol -- The protocol used at the Fp reference point in the ForCES Protocol -- The protocol used at the Fp reference point in the
ForCES Framework in [RFC3746]. ForCES Framework in [RFC3746].
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
skipping to change at page 6, line 5 skipping to change at page 6, line 5
+----------------------------+ +----------------------------+
Figure 2: The TML-PL interface Figure 2: The TML-PL interface
Figure 2 also shows an interface referred to as CEM/FEM[RFC3746] Figure 2 also shows an interface referred to as CEM/FEM[RFC3746]
which is responsible for bootstrapping and parameterization of the which is responsible for bootstrapping and parameterization of the
TML. In its most basic form the CEM/FEM interface takes the form of TML. In its most basic form the CEM/FEM interface takes the form of
a simple static config file which is read on startup in the pre- a simple static config file which is read on startup in the pre-
association phase. association phase.
Section 6 discusses in more details the service interfaces. Appendix B discusses in more details the service interfaces.
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
skipping to change at page 12, line 21 skipping to change at page 12, line 21
This means that the HP messages are always processed first until This means that the HP messages are always processed first until
there are no more left. The LP channel is processed only if a there are no more left. The LP channel is processed only if a
channel that is higher priority than itself has no more messages left channel that is higher priority than itself has no more messages left
to process. This means that under congestion situation, a higher to process. This means that under congestion situation, a higher
priority channel with sufficient messages that occupy the available priority channel with sufficient messages that occupy the available
bandwidth would starve lower priority channel(s). bandwidth would starve lower priority channel(s).
The design intent of the SCTP TML is to tie prioritization as The design intent of the SCTP TML is to tie prioritization as
described in Section 4.2.1.1 and transport congestion control to described in Section 4.2.1.1 and transport congestion control to
provide implicit node congestion control. This is further detailed provide implicit node congestion control. This is further detailed
in Section 5.2. in Appendix A.2.
SCTP channel +----------+ SCTP channel +----------+
Work available | DONE +---<--<--+ Work available | DONE +---<--<--+
| +---+------+ | | +---+------+ |
Y ^ Y ^
| +-->--+ +-->---+ | | +-->--+ +-->---+ |
+-->-->-+ | | | | | +-->-->-+ | | | | |
| | | | | | ^ | | | | | | ^
| ^ ^ Y ^ Y | | ^ ^ Y ^ Y |
^ / \ | | | | | ^ / \ | | | | |
skipping to change at page 14, line 4 skipping to change at page 14, line 4
4.2.1.6. SCTP TML Parameterization 4.2.1.6. SCTP TML Parameterization
The following is a list of parameters needed for booting the TML. It The following is a list of parameters needed for booting the TML. It
is expected these parameters will be extracted via the FEM/CEM is expected these parameters will be extracted via the FEM/CEM
interface for each PL ID. interface for each PL ID.
1. The IP address or a resolvable DNS/hostname of the CE/FE. 1. The IP address or a resolvable DNS/hostname of the CE/FE.
2. Whether to use IPsec or not. If IPsec is used, how to 2. Whether to use IPsec or not. 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 8.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 6700 (Section 7). HP port value is 6700 (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 6701 (Section 7). MP port value is 6701 (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 6702 (Section 7). LP port value is 6702 (Section 6).
4.2.2. Satisfying TML Requirements 4.2.2. Satisfying TML Requirements
[FE-PROTO] section 5 lists requirements that a TML needs to meet. [FE-PROTO] section 5 lists requirements that a TML needs to meet.
This section describes how the SCTP TML satisfies those requirements. This section describes how the SCTP TML satisfies those requirements.
4.2.2.1. Satisfying Reliability Requirement 4.2.2.1. Satisfying Reliability Requirement
As mentioned earlier, a shade of reliability ranges is possible in As mentioned earlier, a shade of reliability ranges is possible in
SCTP. Therefore this requirement is met. SCTP. Therefore this requirement is met.
skipping to change at page 15, line 38 skipping to change at page 15, line 38
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 Section 5.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 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 ignores processing it is busy processing config requests from the CE ignores processing
the redirect packets on the LP channel. If enough redirect packets the redirect packets on the LP channel. If enough redirect packets
accumulate, they are dropped either because the LP channel threshold accumulate, they are dropped either because the LP channel threshold
is exceeded or because they are obsoleted. If on the other hand, the is exceeded or because they are obsoleted. If on the other hand, the
FE has successfully processed the higher priority channels and their FE has successfully processed the higher priority channels and their
skipping to change at page 16, line 12 skipping to change at page 16, line 12
demonstrated in this case, the TML ties transport and node overload demonstrated in this case, the TML ties transport and node overload
implicitly together. implicitly together.
4.2.2.7. Satisfying Encapsulation Requirement 4.2.2.7. Satisfying Encapsulation Requirement
There is no extra encapsulation added by the SCTP TML. There is no extra encapsulation added by the SCTP TML.
In the future, should the need arise, a new SCTP extension/chunk can In the future, should the need arise, a new SCTP extension/chunk can
be defined to meet newer ForCES requirements [RFC4960]. be defined to meet newer ForCES requirements [RFC4960].
5. SCTP TML Channel work 5. SCTP TML Channel Work
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. Section 5.4 discuss is considered out of scope for this document. Appendix A.4 discuss
briefly some constraints that an implementor needs to worry about. briefly some constraints that an implementor needs to worry about.
This document and in particular Section 5.1, Section 5.2 and This document provides suggestions on SCTP channel work
Section 5.3 discuss details of node-level I/O work. implementation in Appendix A.
5.1. SCTP TML Channel Initialization The FE SHOULD do channel connections to the CE in the order of
incrementing priorities i.e. LP socket first, followed by MP and
ending with HP socket connection. The CE, however, MUST NOT assume
that there is ordering of socket connections from any FE.
It is recommended that the FE SHOULD do socket connections to the CE 6. IANA Considerations
in the order of incrementing priorities i.e. LP socket first,
followed by MP and ending with HP socket connection. The CE,
however, MUST NOT assume that there is ordering of socket connections
from any FE. Section 6.1 has more details on the expected
initialization of SCTP channel work.
5.2. Channel work scheduling This document makes request of IANA to reserve SCTP ports 6700, 6701,
and 6702.
7. Security Considerations
The SCTP TML provides the following security services to the PL
level:
o A mechanism to authenticate ForCES CEs and FEs at transport level
in order to prevent the participation of unauthorized CEs and
unauthorized FEs in the control and data path processing of a
ForCES NE.
o A mechanism to ensure message authentication of PL data and
headers transferred from the CE to FE (and vice-versa) in order to
prevent the injection of incorrect data into PL messages.
o A mechanism to ensure the confidentiality of PL data and headers
transferred from the CE to FE (and vice-versa), in order to
prevent disclosure of PL level information transported via the
TML.
Security choices provided by the TML are made by the operator and
take effect during the pre-association phase of the ForCES protocol.
An operator may choose to use all, some or none of the security
services provided by the TML in a CE-FE connection.
When operating under a secured environment, or for other operational
concerns (in some cases performance issues) the operator may turn off
all the security functions between CE and FE.
IP Security Protocol (IPsec) [RFC4301] is used to provide needed
security mechanisms.
IPsec is an IP level security scheme transparent to the higher-layer
applications and therefore can provide security for any transport
layer protocol. This gives IPsec the advantage that it can be used
to secure everything between the CE and FE without expecting the TML
implementation to be aware of the details.
The IPsec architecture is designed to provide message integrity and
message confidentiality outlined in the TML security requirements
([FE-PROTO]). Mutual authentication and key exchange protocol are
provided by Internet Key Exchange (IKE)[RFC4109].
7.1. IPsec Usage
A ForCES FE or CE MUST support the following:
o Internet Key Exchange (IKE)[RFC4109] with certificates for
endpoint authentication.
o Transport Mode Encapsulating Security Payload (ESP)[RFC4303].
o HMAC-SHA1-96 [RFC2404] for message integrity protection
o AES-CBC with 128-bit keys [RFC3602] for message confidentiality.
o Replay protection[RFC4301].
It is expected to be possible for the CE or FE to be operationally
configured to negotiate other cipher suites and even use manual
keying.
7.1.1. SAD and SPD setup
To minimize the operational configuration it is recommended that only
the IANA issued SCTP protocol number(132) be used as a selector in
the Security Policy Database (SPD) for ForCES. In such a case only a
single SPD and SAD entry is needed.
It should be straightforward to extend such a policy to alternatively
use the 3 SCTP TML port numbers as SPD selectors. But as noted above
this choice will require increased number of SPD entries.
In scenarios where multiple IP addresses are used within a single
association, and there is desire to configure different policies on a
per IP address, then it is recommended to follow [RFC3554]
8. Acknowledgements
The authors would like to thank Joel Halpern, Michael Tuxen, Randy
Stewart and Evangelos Haleplidis for engaging us in discussions that
have made this draft better.
9. References
9.1. Normative References
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version
1 (IKEv1)", RFC 4109, May 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
September 2007.
9.2. Informative References
[FE-MODEL]
Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
Model", October 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", November 2008.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[SCTP-API]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Feb. 2009.
Appendix A. SCTP TML Channel Work Implementation
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
other ForCES nodes:
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose
which of the peer nodes to process.
2. Node-level I/O work where a ForCES node, handles the three SCTP
TML channels separately for each single ForCES endpoint.
NE-level scheduling definition is left up to the implementation and
is considered out of scope for this document. Appendix A.4 discuss
briefly some constraints that an implementor needs to worry about.
This document and in particular Appendix A.1, Appendix A.2 and
Appendix A.3 discuss details of node-level I/O work.
A.1. SCTP TML Channel Initialization
As discussed in Section 5, it is recommended that the FE SHOULD do
socket connections to the CE in the order of incrementing priorities
i.e. LP socket first, followed by MP and ending with HP socket
connection. The CE, however, MUST NOT assume that there is ordering
of socket connections from any FE. Appendix B.1 has more details on
the expected initialization of SCTP channel work.
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. The implementor is work quanta, etc) not described in this document. The implementor is
left to take care of those details. left to take care of those details.
The CE(s) and FE(s) are coupled together in the principles of the The CE(s) and FE(s) are coupled together in the principles of the
scheduling scheme described here to tie together node overload with scheduling scheme described here to tie together node overload with
transport congestion. The design intent is to provide the highest transport congestion. The design intent is to provide the highest
possible robust work throughput for the NE under any network or possible robust work throughput for the NE under any network or
processing congestion. processing congestion.
5.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 which creates ForCES
work to be executed by the FE. work to be executed by the FE.
skipping to change at page 17, line 35 skipping to change at page 21, line 16
from other NEs via external (to the NE) interfaces. After some from other NEs via external (to the NE) interfaces. After some
processing, such packets are sent to the CE. processing, such packets are sent to the CE.
It is worth emphasizing at this point again that the SCTP TML It is worth emphasizing at this point again that the SCTP TML
processes the channel work in strict priority. For example, as long processes the channel work in strict priority. For example, as long
as there are messages to send to the CE on the HP channel, they will as there are messages to send to the CE on the HP channel, they will
be processed first until there are no more left before processing the be processed first until there are no more left before processing the
next priority work (which is to read new messages on the HP channel next priority work (which is to read new messages on the HP channel
incoming from the CE). incoming from the CE).
5.2.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. Transmitting any outstanding HP work it needs for the FE(s)
to complete. to complete.
skipping to change at page 18, line 15 skipping to change at page 21, line 44
4. Incoming Redirect work in the form of control packets that come 4. Incoming Redirect work in the form of control packets that come
from other NEs via external (to the NE) interfaces on the FE(s). from other NEs via external (to the NE) interfaces on the FE(s).
It is worth to repeat for emphasis again that the SCTP TML processes It is worth to repeat for emphasis again that the SCTP TML processes
the channel work in strict priority. For example, if there are the channel work in strict priority. For example, if there are
messages incoming from an FE on the HP channel, they will be messages incoming from an FE on the HP channel, they will be
processed first until there are no more left before processing the processed first until there are no more left before processing the
next priority work which is to transmit any outstanding HP channel next priority work which is to transmit any outstanding HP channel
messages going to the FE. messages going to the FE.
5.3. SCTP TML Channel Termination A.3. SCTP TML Channel Termination
Section 6.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 Section 6.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 got around
to processing yet). By virtue of the CE closing the connections, the to processing yet). By virtue of the CE closing the connections, the
FE will immediately be asynchronously notified and will not have to FE will immediately be asynchronously notified and will not have to
process any outstanding commands from the CE. process any outstanding commands from the CE.
5.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 CE;
whereas one FE has a few HP messages that need to be processed by the whereas one FE has a few HP messages that need to be processed by the
CE, another may have infinite HP messages. The scheduling scheme may CE, another may have infinite HP messages. The scheduling scheme may
decide to use a quota scheduling system to ensure that the second FE decide to use a quota scheduling system to ensure that the second FE
does not hog the CE cycles. does not hog the CE cycles.
skipping to change at page 19, line 10 skipping to change at page 22, line 39
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 DoS attack
from hostile entities and always achieves a maximum stable workload from hostile entities and always achieves a maximum stable workload
processing level. For the sake of illustration consider again two processing level. For the sake of illustration consider again two
FEs connected to a CE. Consider FE1 as having a large number of HP FEs connected to a CE. Consider FE1 as having a large number of HP
and MP messages and FE2 having a large number of MP and LP messages. and MP messages and FE2 having a large number of MP and LP messages.
The scheduling scheme needs to ensure that while FE1 always gets its The scheduling scheme needs to ensure that while FE1 always gets its
messages processed, at some point we allow FE2 messages to be messages processed, at some point we allow FE2 messages to be
processed. A promotion and preemption based scheduling could be used processed. A promotion and preemption based scheduling could be used
by the CE to resolve this issue. by the CE to resolve this issue.
6. Service Interface Appendix B. Service Interface
This section provides high level service interface between FEM/CEM This section provides high level service interface between FEM/CEM
and TML, the PL and TML, and between local and remote TMLs. The and TML, the PL and TML, and between local and remote TMLs. The
intent of this interface discussion is to provide general guidelines. intent of this interface discussion is to provide general guidelines.
The implementer is expected to worry about details and even follow a The implementer is expected to worry about details and even follow a
different approach if needed. different approach if needed.
The theory of operation for the PL-TML service is as follows: The theory of operation for the PL-TML service is as follows:
1. The PL starts up and bootstraps the TML. The end result of a 1. The PL starts up and bootstraps the TML. The end result of a
skipping to change at page 19, line 37 skipping to change at page 23, line 19
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 maybe either unsolicited events
from the FE PL, control message redirects from/to the CE to/from from the FE PL, control message redirects from/to the CE to/from
FE, and configuration from the CE to the FE and their responses FE, and configuration from the CE to the FE and their responses
flowing from the FE to the CE. 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.
6.1. TML Boot-strapping B.1. TML Boot-strapping
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 3 channels to the CE. The
skipping to change at page 21, line 5 skipping to change at page 24, line 45
CEM, the TML on the CE side proceeds to initialize the 3 channels to CEM, the TML on the CE side proceeds to initialize the 3 channels to
listen to remote connections from the FEs. The success or failure listen to remote connections from the FEs. The success or failure
indication is passed on to the CE PL level (in the same manner as was indication is passed on to the CE PL level (in the same manner as was
done in the FE). done in the FE).
Post boot-up, the CE TML waits for connections from the FEs. Upon a Post boot-up, the CE TML waits for connections from the FEs. Upon a
successful connection by an FE, the CE TML level keeps track of the 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
Section 6.3 and Figure 8). Appendix B.3 and Figure 8).
6.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. issued by the CE.
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. by closing the sockets used to communicate to the CE.
FE PL FE TML CE TML CE PL FE PL FE TML CE TML CE PL
skipping to change at page 21, line 43 skipping to change at page 25, line 35
|<-----------| | | |<-----------| | |
| | | | | | | |
Figure 7: FE Shutting down Figure 7: FE Shutting down
On the CE side, a TML level disconnection would result in possible On the CE side, a TML level disconnection would result in possible
cleanup of the FE state. Optionally, depending on the cleanup of the FE state. Optionally, depending on the
implementation, there may be need to inform the PL about the TML implementation, there may be need to inform the PL about the TML
disconnection. disconnection.
6.3. TML Sending and Receiving B.3. TML Sending and Receiving
The TML is agnostic to the nature of the PL message it delivers to The TML is agnostic to the nature of the PL message it delivers to
the remote TML (which subsequently delivers the message to its PL). the remote TML (which subsequently delivers the message to its PL).
Figure 8 shows an example of a message exchange originated at the FE Figure 8 shows an example of a message exchange originated at the FE
and sent to the CE (such as a ForCES association message) which and sent to the CE (such as a ForCES association message) which
illustrates all the necessary service interfaces for sending and illustrates all the necessary service interfaces for sending and
receiving. 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.
skipping to change at page 23, line 4 skipping to change at page 26, line 45
When the CE TML receives the ForCES message on the channel it was When the CE TML receives the ForCES message on the channel it was
sent on, it demultiplexes the message to the CE PL. sent on, 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 to the TML the response. And as in the case
of FE PL, the CE TML picks the channel to send on before sending. of FE PL, the CE TML picks the channel to send on before sending.
The processing of the ForCES message upon arriving at the FE TML and The processing of the ForCES message upon arriving at the FE TML and
delivery to the FE PL is similar to the CE side equivalent as shown delivery to the FE PL is similar to the CE side equivalent as shown
above in Section 6.3. above in Appendix B.3.
7. IANA Considerations
This document makes request of IANA to reserve SCTP ports 6700, 6701,
and 6702.
8. Security Considerations
The SCTP TML provides the following security services to the PL
level:
o A mechanism to authenticate ForCES CEs and FEs at transport level
in order to prevent the participation of unauthorized CEs and
unauthorized FEs in the control and data path processing of a
ForCES NE.
o A mechanism to ensure message authentication of PL data and
headers transferred from the CE to FE (and vice-versa) in order to
prevent the injection of incorrect data into PL messages.
o A mechanism to ensure the confidentiality of PL data and headers
transferred from the CE to FE (and vice-versa), in order to
prevent disclosure of PL level information transported via the
TML.
Security choices provided by the TML are made by the operator and
take effect during the pre-association phase of the ForCES protocol.
An operator may choose to use all, some or none of the security
services provided by the TML in a CE-FE connection.
When operating under a secured environment, or for other operational
concerns (in some cases performance issues) the operator may turn off
all the security functions between CE and FE.
IP Security Protocol (IPsec) [RFC4301] is used to provide needed
security mechanisms.
IPsec is an IP level security scheme transparent to the higher-layer
applications and therefore can provide security for any transport
layer protocol. This gives IPsec the advantage that it can be used
to secure everything between the CE and FE without expecting the TML
implementation to be aware of the details.
The IPsec architecture is designed to provide message integrity and
message confidentiality outlined in the TML security requirements
([FE-PROTO]). Mutual authentication and key exchange protocol are
provided by Internet Key Exchange (IKE)[RFC4109].
8.1. IPsec Usage
A ForCES FE or CE MUST support the following:
o Internet Key Exchange (IKE)[RFC4109] with certificates for
endpoint authentication.
o Transport Mode Encapsulating Security Payload (ESP)[RFC4303].
o HMAC-SHA1-96 [RFC2404] for message integrity protection
o AES-CBC with 128-bit keys [RFC3602] for message confidentiality.
o Replay protection[RFC4301].
It is expected to be possible for the CE or FE to be operationally
configured to negotiate other cipher suites and even use manual
keying.
8.1.1. SAD and SPD setup
To minimize the operational configuration it is recommended that only
the IANA issued SCTP protocol number(132) be used as a selector in
the Security Policy Database (SPD) for ForCES. In such a case only a
single SPD and SAD entry is needed.
It should be straightforward to extend such a policy to alternatively
use the 3 SCTP TML port numbers as SPD selectors. But as noted above
this choice will require increased number of SPD entries.
In scenarios where multiple IP addresses are used within a single
association, and there is desire to configure different policies on a
per IP address, then it is recommended to follow [RFC3554]
9. Acknowledgements
The authors would like to thank Joel Halpern, Michael Tuxen, Randy
Stewart and Evangelos Haleplidis for engaging us in discussions that
have made this draft better.
10. References
10.1. Normative References
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R.
Stewart, "On the Use of Stream Control Transmission
Protocol (SCTP) with IPsec", RFC 3554, July 2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version
1 (IKEv1)", RFC 4109, May 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
September 2007.
10.2. Informative References
[FE-MODEL]
Halpern, J. and J. Hadi Salim, "ForCES Forwarding Element
Model", October 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", November 2008.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004.
[SCTP-API]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Feb. 2009.
Authors' Addresses Authors' Addresses
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@mojatatu.com Email: hadi@mojatatu.com
 End of changes. 30 change blocks. 
199 lines changed or deleted 224 lines changed or added

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