draft-ietf-forces-sctptml-07.txt   draft-ietf-forces-sctptml-08.txt 
Network Working Group J. Hadi Salim Network Working Group J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Intended status: Standards Track K. Ogawa Intended status: Standards Track K. Ogawa
Expires: May 27, 2010 NTT Corporation Expires: July 23, 2010 NTT Corporation
November 23, 2009 January 19, 2010
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP based TML (Transport Mapping Layer) for ForCES protocol
draft-ietf-forces-sctptml-07 draft-ietf-forces-sctptml-08
Abstract Abstract
This document defines the SCTP based TML (Transport Mapping Layer) This document defines the SCTP based TML (Transport Mapping Layer)
for the ForCES protocol. It explains the rationale for choosing the for the ForCES protocol. It explains the rationale for choosing the
SCTP (Stream Control Transmission Protocol) and also describes how SCTP (Stream Control Transmission Protocol) and also describes how
this TML addresses all the requirements required by and the ForCES this TML addresses all the requirements required by and the ForCES
protocol. protocol.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 27, 2010. This Internet-Draft will expire on July 23, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 4
3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 6
3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 7
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 7 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 7 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8
4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 8 4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 9
4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 9 4.2.1. SCTP TML Channels . . . . . . . . . . . . . . . . . . 10
4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 14 4.2.2. Satisfying TML Requirements . . . . . . . . . . . . . 15
5. SCTP TML Channel Work . . . . . . . . . . . . . . . . . . . . 16 5. SCTP TML Channel Work . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 18 7.1.1. SAD and SPD setup . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Suggested SCTP TML Channel Work Implementation . . . 20 Appendix A. Suggested SCTP TML Channel Work Implementation . . . 21
A.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 20 A.1. SCTP TML Channel Initialization . . . . . . . . . . . . . 21
A.2. Channel work scheduling . . . . . . . . . . . . . . . . . 20 A.2. Channel work scheduling . . . . . . . . . . . . . . . . . 22
A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 21 A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 22
A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 21 A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 22
A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 22 A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 23
A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 22 A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 24
Appendix B. Suggested Service Interface . . . . . . . . . . . . . 23 Appendix B. Suggested Service Interface . . . . . . . . . . . . . 24
B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 23 B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 25
B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 26
B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 26 B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Definitions 1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
The following definitions are taken from [RFC3654]and [RFC3746]: The following definitions are taken from [RFC3654]and [RFC3746]:
Logical Functional Block (LFB) -- A template that represents a fine- Logical Functional Block (LFB) -- A template that represents a fine-
skipping to change at page 10, line 36 skipping to change at page 10, line 36
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 separate and prioritize SCTP layers. There are 3 channels used to group and prioritize the
the different types of ForCES traffic. Each channel constitutes a work for different types of ForCES traffic. Each channel constitutes
socket interface. It should be noted that all SCTP channels are an SCTP socket interface which has different properties. It should
congestion aware (and for that reason that detail is left out of the be noted that all SCTP channels are congestion aware (and for that
description of the 3 channels). SCTP port 6704, 6705, 6706 are used reason that detail is left out of the description of the 3 channels).
for the higher, medium and lower priority channels respectively. SCTP port 6704, 6705, 6706 are used for the higher, medium and lower
SCTP Payload Protocol ID (PPID) values of 21, 22, and 23 are used for priority channels respectively. SCTP Payload Protocol ID (PPID)
the higher, medium and lower priority channels respectively. values of 21, 22, and 23 are used for the higher, medium and lower
priority channels respectively.
4.2.1.1. Justifying Choice of 3 Sockets 4.2.1.1. Justifying Choice of 3 Sockets
SCTP allows up to 64K streams to be sent over a single socket SCTP allows up to 64K streams to be sent over a single socket
interface. The authors initially envisioned using a single socket interface. The authors initially envisioned using a single socket
for all three channels (mapping a channel to an SCTP stream). This for all three channels (mapping a channel to an SCTP stream). This
simplifies programming of the TML as well as conserves use of SCTP simplifies programming of the TML as well as conserves use of SCTP
ports. ports.
Further analysis revealed head of line blocking issues with this Further analysis revealed head of line blocking issues with this
skipping to change at page 14, line 5 skipping to change at page 13, line 37
that are a higher priority than itself has no more messages left to that are a higher priority than itself has no more messages left to
process. This means that under congestion situation, a higher 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 processing prioritization The design intent of the SCTP TML is to tie processing prioritization
as described in Section 4.2.1.1 and transport congestion control to as 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 Appendix A.2. in Appendix A.2.
It should be emphasized that the work scheduling prioritization
scheme prescribed in this document is receiver based processing.
Fully arrived packets on any of the channels are a source of work
whose output may result in transmitted packets. However, we have no
control on the order in which SCTP/OS/network chooses to send
transmitted packets across and make them available to the receiver.
This is a limitation that we try to ameliorate by our choice of
channel properties, ForCES message grouping and the tying of CE and
FE work scheduling. And while that helps us ameliorate some of these
issues it does not fully resolve all.
From a ForCES perspective, we can tolerate some reordering. Example:
If an FE transmits a config response (HP), followed by 10000 OSPF
redirect packets(LP) and the CE gets 5 OSPF redirects (LP) first
before the config response(HP), that is tolerable. What matters is
the CE gets to processing the HP message soon (instead of sitting in
long periods of time processing OSPF packets which would have
happened if we use a single socket with 3 streams). This is
particularly important in order to deal well with node overload as
discussed in Section 4.2.2.6.
SCTP channel +----------+ SCTP channel +----------+
Work available | DONE +---<--<--+ Work available | DONE +---<--<--+
| +---+------+ | | +---+------+ |
Y ^ Y ^
| +-->--+ +-->---+ | | +-->--+ +-->---+ |
+-->-->-+ | | | | | +-->-->-+ | | | | |
| | | | | | ^ | | | | | | ^
| ^ ^ Y ^ Y | | ^ ^ Y ^ Y |
^ / \ | | | | | ^ / \ | | | | |
| / \ | ^ | ^ ^ | / \ | ^ | ^ ^
skipping to change at page 15, line 34 skipping to change at page 15, line 45
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 3 sockets in conjunction with the partial-reliability
feature, both timeliness and prioritization requirements are feature[RFC3758], both timeliness and prioritization requirements are
addressed. 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 fulfil 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.
skipping to change at page 16, line 23 skipping to change at page 16, line 33
o With the ADDIP feature, one can migrate IP addresses to other o With the ADDIP feature, one can migrate IP addresses to other
nodes at runtime. This is not unlike the VRRP[RFC3768] protocol nodes at runtime. This is not unlike the VRRP[RFC3768] protocol
use. This feature is used in addition to multi-homing in a use. This feature is used in addition to multi-homing in a
planned migration of activity from one FE/CE to another. In such planned migration of activity from one FE/CE to another. In such
a case, part of the provisioning recipe at the CE for replacing an a case, part of the provisioning recipe at the CE for replacing an
FE involves migrating activity of one FE to another. FE involves migrating activity of one FE to another.
4.2.2.6. Satisfying 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 scheduling design for socket, to be used within any FE-CE setup. The work scheduling
processing the TML channels (Section 4.2.1.5) is strict priority. A design for processing the TML channels (Section 4.2.1.5) is strict
fundamental desire of the strict prioritization is to ensure that priority. A fundamental desire of the strict prioritization is to
more important processing work always gets node resources over lesser ensure that more important processing work always gets node resources
important work. over lesser 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
skipping to change at page 19, line 13 skipping to change at page 19, line 23
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].
It is expected to be possible for the CE or FE to be operationally A compliant implementation SHOULD provide operational means for
configured to negotiate other cipher suites and even use manual configuring the CE and FE to negotiate other cipher suites and even
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 only
the IANA issued SCTP protocol number(132) be used as a selector in 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 the Security Policy Database (SPD) for ForCES. In such a case only a
single SPD and SAD entry is needed. single SPD and SAD entry is needed.
It should be straightforward to extend such a policy to alternatively Setup MAY alternatively extend the above policy so that it uses the 3
use the 3 SCTP TML port numbers as SPD selectors. But as noted above SCTP TML port numbers as SPD selectors. But as noted above this
this choice will require increased number of SPD entries. choice will require 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 it is RECOMMENDED to follow [RFC3554]
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
skipping to change at page 20, line 21 skipping to change at page 20, line 30
(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.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, Algorithm and Its Use with IPsec", RFC 3602,
September 2003. September 2003.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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
skipping to change at page 20, line 45 skipping to change at page 21, line 11
[I-D.ietf-forces-model] [I-D.ietf-forces-model]
Halpern, J. and J. Salim, "ForCES Forwarding Element Halpern, J. and J. Salim, "ForCES Forwarding Element
Model", draft-ietf-forces-model-16 (work in progress), Model", draft-ietf-forces-model-16 (work in progress),
October 2008. October 2008.
[I-D.ietf-tsvwg-sctpsocket] [I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-19 (work in progress), draft-ietf-tsvwg-sctpsocket-20 (work in progress),
February 2009. 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)", [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
RFC 3768, April 2004. RFC 3768, April 2004.
 End of changes. 15 change blocks. 
62 lines changed or deleted 88 lines changed or added

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