draft-ietf-forces-sctptml-04.txt   draft-ietf-forces-sctptml-05.txt 
Network Working Group J. Hadi Salim Network Working Group J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Expires: January 2, 2010 K. Ogawa Expires: February 12, 2010 K. Ogawa
NTT Corporation NTT Corporation
July 1, 2009 August 11, 2009
SCTP based TML (Transport Mapping Layer) for ForCES protocol SCTP based TML (Transport Mapping Layer) for ForCES protocol
draft-ietf-forces-sctptml-04 draft-ietf-forces-sctptml-05
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 January 2, 2010. This Internet-Draft will expire on February 12, 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 19 skipping to change at page 2, line 19
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3 3. Protocol Framework Overview . . . . . . . . . . . . . . . . . 3
3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The PL . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. The TML . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5 3.2.1. TML and PL Interfaces . . . . . . . . . . . . . . . . 5
3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6 3.2.2. TML Parameterization . . . . . . . . . . . . . . . . . 6
4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6 4. SCTP TML overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8 4.1. Rationale for using SCTP for TML . . . . . . . . . . . . . 8
4.2. Meeting TML requirements . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. IPsec Usage . . . . . . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. SCTP TML Channel Work Implementation . . . . . . . . 19 Appendix A. Suggested SCTP TML Channel Work Implementation . . . 20
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 . . . . . . . . . . . . . . . . . 21
A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 20 A.2.1. FE Channel work scheduling . . . . . . . . . . . . . . 21
A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 21 A.2.2. CE Channel work scheduling . . . . . . . . . . . . . . 22
A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 21 A.3. SCTP TML Channel Termination . . . . . . . . . . . . . . . 22
A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 22 A.4. SCTP TML NE level channel scheduling . . . . . . . . . . . 23
Appendix B. Service Interface . . . . . . . . . . . . . . . . . . 22 Appendix B. Suggested Service Interface . . . . . . . . . . . . . 23
B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 23 B.1. TML Boot-strapping . . . . . . . . . . . . . . . . . . . . 24
B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 24 B.2. TML Shutdown . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 25 B.3. TML Sending and Receiving . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Definitions 1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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]:
ForCES Protocol -- The protocol used at the Fp reference point in the ForCES Protocol -- The protocol used at the Fp reference point in the
ForCES Framework in [RFC3746]. ForCES Framework in [RFC3746].
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
architecture that defines the ForCES protocol architecture and the architecture that defines the ForCES protocol architecture and the
state transfer mechanisms as defined in [FE-PROTO]. state transfer mechanisms as defined in [FE-PROTO].
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
skipping to change at page 10, line 4 skipping to change at page 10, line 42
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 separate and prioritize
the different types of ForCES traffic. Each channel constitutes a the different types of ForCES traffic. Each channel constitutes a
socket interface. It should be noted that all SCTP channels are socket interface. It should be noted that all SCTP channels are
congestion aware (and for that reason that detail is left out of the 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 description of the 3 channels). SCTP port 6700, 6701, 6702 are used
for the higher, medium and lower priority channels respectively. for the higher, medium and lower priority channels respectively.
SCTP Payload Protocol ID (PPID) 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 10, line 25 skipping to change at page 11, line 19
delivery could block higher priority packets (needing reliable delivery could block higher priority packets (needing reliable
delivery) under congestion situation for an indeterminate period of delivery) under congestion situation for an indeterminate period of
time (depending on how many outstanding lower priority packets are time (depending on how many outstanding lower priority packets are
pending). For this reason, we elected to go with mapping each of the pending). For this reason, we elected to go with mapping each of the
three channels to a different SCTP socket (instead of a different three channels to a different SCTP socket (instead of a different
stream within a single socket). stream within a single socket).
4.2.1.2. Higher Priority, Reliable channel 4.2.1.2. Higher Priority, Reliable channel
The higher priority (HP) channel uses a standard SCTP reliable socket The higher priority (HP) channel uses a standard SCTP reliable socket
on port 6700. It is used for CE solicited messages and their on port 6700. SCTP PPID 21 is used for all messages on the HP
channel. The HP channel is used for CE solicited messages and their
responses: responses:
1. ForCES configuration messages flowing from CE to FE and responses 1. ForCES configuration messages flowing from CE to FE and responses
from the FE to CE. from the FE to CE.
2. ForCES query messages flowing from CE to FE and responses from 2. ForCES query messages flowing from CE to FE and responses from
the FE to the CE. the FE to the CE.
It is recommended that PL priorities 4-7 be used for this channel and PL priorities 4-7 MUST be used for all PL messages using this
that the following PL messages use the HP channel for transport: channel. The following PL messages MUST use the HP channel for
transport:
o Association Setup o Association Setup (default priority: 7)
o Association Setup Response o Association Setup Response (default priority: 7)
o Association Teardown o Association Teardown (default priority: 7)
o Config o Config (default priority: 4)
o Config Response o Config Response (default priority: 4)
o Query o Query (default priority: 4)
o Query Response o Query Response (default priority: 4)
Although an implementation may choose different values from the
defined range (4-7), it is strongly recommended that default
priorities be used. A response to a ForCES message MUST contain the
same priority as the request. Example, a config sent by the CE with
priority 5 MUST have a config-response from the FE with priority 5.
4.2.1.3. Medium Priority, Semi-Reliable channel 4.2.1.3. Medium Priority, Semi-Reliable channel
The medium priority (MP) channel uses SCTP-PR on port 6701. Time The medium priority (MP) channel uses SCTP-PR on port 6701. SCTP
limits on how long a message is valid are set on each outgoing PPID 22 MUST be used for all messages on the MP channel. Time limits
message. This channel is used for events from the FE to the CE that on how long a message is valid are set on each outgoing message.
are obsoleted over time. Events that are accumulative in nature and This channel is used for events from the FE to the CE that are
are recoverable by the CE (by issuing a query to the FE) can tolerate 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 use this channel. For example, a lost events and therefore should use this channel. For example, a
generated event which carries the value of a counter that is generated event which carries the value of a counter that is
monotonically incrementing fits to use this channel. monotonically incrementing fits to use this channel.
It is recommended that PL priorities 2-3 be used for this channel and PL priority 3 MUST be used for PL messages on this channel. The
that the following PL messages use the MP channel for transport: following PL messages MUST use the MP channel for transport:
o Event Notification o Event Notification (default priority: 3)
4.2.1.4. Lower Priority, Unreliable channel 4.2.1.4. Lower Priority, Unreliable channel
The lower priority (LP) channel uses SCTP port 6702. This channel The lower priority (LP) channel uses SCTP port 6702. SCTP PPID 23 is
also uses SCTP-PR with lower timeout values than the MP channel. The used for all messages on the LP channel. The LP channel also MUST
use SCTP-PR with lower timeout values than the MP channel. The
reason an unreliable channel is used for redirect messages is to reason an unreliable channel is used for redirect messages is to
allow the control protocol at both the CE and its peer-endpoint to allow the control protocol at both the CE and its peer-endpoint to
take charge of how the end-to-end semantics of the said control take charge of how the end-to-end semantics of the said control
protocol's operations. For example: protocol's operations. For example:
1. Some control protocols are reliable in nature, therefore making 1. Some control protocols are reliable in nature, therefore making
this channel reliable introduces an extra layer of reliability this channel reliable introduces an extra layer of reliability
which could be harmful. So any end-to-end retransmits will which could be harmful. So any end-to-end retransmits will
happen from remote. happen from remote.
2. Some control protocols may desire to have obsolescence of 2. Some control protocols may desire to have obsolescence of
messages over retransmissions; making this channel reliable messages over retransmissions; making this channel reliable
contradicts that desire. contradicts that desire.
Given ForCES PL level heartbeats are traffic sensitive, sending them Given ForCES PL level heartbeats are traffic sensitive, sending them
over the LP channel also makes sense. If the other end is not over the LP channel also makes sense. If the other end is not
processing other channels it will eventually get heartbeats; and if processing other channels it will eventually get heartbeats; and if
it is busy processing other channels heartbeats will be obsoleted it is busy processing other channels heartbeats will be obsoleted
locally over time (and it does not matter if they did not make it). locally over time (and it does not matter if they did not make it).
It is recommended that PL priorities 0-1 be used for this channel and PL priorities 1-2 MUST be used for PL messages on this channel. PL
that that the following PL messages use the LP channel for transport: messages that MUST use the MP channel for transport are:
o Packet Redirect
o Heartbeats o Packet Redirect (default priority: 2)
o Heartbeats (default priority: 1)
4.2.1.5. Scheduling of The 3 Channels 4.2.1.5. Scheduling of The 3 Channels
Strict priority work-conserving scheduling is used to process both on Strict priority work-conserving scheduling is used to process both on
sending and receiving (of the PL messages) by the TML Core as shown sending and receiving (of the PL messages) by the TML Core as shown
in Figure 5. in Figure 5.
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
skipping to change at page 13, line 27 skipping to change at page 14, line 27
^ / HP work \ ^ /there\ ^ /there\ ^ ^ / HP work \ ^ /there\ ^ /there\ ^
| \ ? / | /MP work\ | /LP work\ | | \ ? / | /MP work\ | /LP work\ |
| \ / | \ ? / | \ ? / | | \ / | \ ? / | \ ? / |
| \ / | \ / | \ / ^ | \ / | \ / | \ / ^
| \ / ^ \ / ^ \ / | | \ / ^ \ / ^ \ / |
| \ / | \ / | \ / | | \ / | \ / | \ / |
^ Y-->-->-->+ Y-->-->-->+ Y->->->-+ ^ Y-->-->-->+ Y-->-->-->+ Y->->->-+
| | NO | NO | NO | | NO | NO | NO
| | | | | | | |
| Y Y Y | Y Y Y
| | YES | YES | | | YES | YES | YES
^ | | | ^ | | |
| Y Y Y | Y Y Y
| +----+------+ +---|-------+ +----|------+ | +----+------+ +---|-------+ +----|------+
| |- process | |- process | |- process | | |- process | |- process | |- process |
| | HP work | | MP work | | LP work | | | HP work | | MP work | | LP work |
| +------+----+ +-----+-----+ +-----+-----+ | +------+----+ +-----+-----+ +-----+-----+
| | | | | | | |
^ Y Y Y ^ Y Y Y
| | | | | | | |
| Y Y Y | Y Y Y
+--<--<---+--<--<----<----+-----<---<-----+ +--<--<---+--<--<----<----+-----<---<-----+
Figure 5: SCTP TML Strict Priority Scheduling Figure 5: SCTP TML Strict Priority Scheduling
4.2.1.6. SCTP TML Parameterization 4.2.1.6. SCTP TML Parameterization
The following is a list of parameters needed for booting the TML. It The following is a list of parameters needed for booting the TML. It
is expected these parameters will be extracted via the FEM/CEM is expected these parameters will be extracted via the FEM/CEM
interface for each PL ID. interface for each PL ID.
1. The IP address or a resolvable DNS/hostname of the CE/FE. 1. The IP address(es) or a resolvable DNS/hostname(s) of the CE/FE.
2. Whether to use IPsec or not. If IPsec is used, how to 2. Whether 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 7.1 described in Section 7.1
3. The HP SCTP port, as discussed in Section 4.2.1.2. The default 3. The HP SCTP port, as discussed in Section 4.2.1.2. The default
HP port value is 6700 (Section 6). 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 6). MP port value is 6701 (Section 6).
skipping to change at page 15, line 44 skipping to change at page 16, line 44
gets prioritized over LP channels. The preferential scheduling only gets prioritized over LP channels. The preferential scheduling only
kicks in when there is node overload regardless of whether there is kicks in when there is node overload regardless of whether there is
transport congestion. As a result of the preferential work transport congestion. As a result of the preferential work
treatment, the ForCES node achieves a robust steady processing treatment, the ForCES node achieves a robust steady processing
capacity. Refer to Appendix A.2 for details on scheduling. capacity. Refer to Appendix A.2 for details on scheduling.
For an example of how the overload prevention works: consider a For an example of how the overload prevention works: consider a
scenario where an overwhelming amount redirected packets (from scenario where an overwhelming amount 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 essentially ignores
the redirect packets on the LP channel. If enough redirect packets processing the redirect packets on the LP channel. If enough
accumulate, they are dropped either because the LP channel threshold redirect packets accumulate, they are dropped either because the LP
is exceeded or because they are obsoleted. If on the other hand, the channel threshold is exceeded or because they are obsoleted. If on
FE has successfully processed the higher priority channels and their the other hand, the FE has successfully processed the higher priority
related work, then it can proceed and process the LP channel. So as channels and their related work, then it can proceed and process the
demonstrated in this case, the TML ties transport and node overload LP channel. So as demonstrated in this case, the TML ties transport
implicitly together. and node overload implicitly together.
4.2.2.7. Satisfying Encapsulation Requirement 4.2.2.7. Satisfying Encapsulation Requirement
There is no extra encapsulation added by the SCTP TML. The SCTP TML sets SCTP PPIDs to identify channels used as described
in Section 4.2.1.1.
In the future, should the need arise, a new SCTP extension/chunk can
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
skipping to change at page 16, line 38 skipping to change at page 17, line 36
implementation in Appendix A. implementation in Appendix A.
The FE SHOULD do channel connections to the CE in the order of The FE SHOULD do channel connections to the CE in the order of
incrementing priorities i.e. LP socket first, followed by MP and incrementing priorities i.e. LP socket first, followed by MP and
ending with HP socket connection. The CE, however, MUST NOT assume ending with HP socket connection. The CE, however, MUST NOT assume
that there is ordering of socket connections from any FE. that there is ordering of socket connections from any FE.
6. IANA Considerations 6. IANA Considerations
This document makes request of IANA to reserve SCTP ports 6700, 6701, This document makes request of IANA to reserve SCTP ports 6700, 6701,
and 6702. and 6702. This document also requests for SCTP PPID 21, 22, and 23.
7. Security Considerations 7. Security Considerations
The SCTP TML provides the following security services to the PL The SCTP TML provides the following security services to the PL
level: level:
o A mechanism to authenticate ForCES CEs and FEs at transport level o A mechanism to authenticate ForCES CEs and FEs at transport level
in order to prevent the participation of unauthorized CEs and in order to prevent the participation of unauthorized CEs and
unauthorized FEs in the control and data path processing of a unauthorized FEs in the control and data path processing of a
ForCES NE. ForCES NE.
skipping to change at page 18, line 25 skipping to change at page 19, line 23
use the 3 SCTP TML port numbers as SPD selectors. But as noted above use the 3 SCTP TML port numbers as SPD selectors. But as noted above
this choice will require increased number of SPD entries. this 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 and Evangelos Haleplidis for engaging us in discussions that Stewart, Evangelos Haleplidis and Chuanhuang Li for engaging us in
have made this draft better. discussions that have made this draft better.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[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
skipping to change at page 19, line 40 skipping to change at page 20, line 37
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.
[SCTP-API] [SCTP-API]
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)", Feb. 2009. Transmission Protocol (SCTP)", Feb. 2009.
Appendix A. SCTP TML Channel Work Implementation Appendix A. Suggested SCTP TML Channel Work Implementation
As mentioned in Section 5, there are two levels of TML channel work As mentioned in Section 5, there are two levels of TML channel work
within an NE when a ForCES node (CE or FE) is connected to multiple within an NE when a ForCES node (CE or FE) is connected to multiple
other ForCES nodes: other ForCES nodes:
1. NE-level I/O work where a ForCES node (CE or FE) needs to choose 1. NE-level I/O work where a ForCES node (CE or FE) needs to choose
which of the peer nodes to process. which of the peer nodes to process.
2. Node-level I/O work where a ForCES node, handles the three SCTP 2. Node-level I/O work where a ForCES node, handles the three SCTP
TML channels separately for each single ForCES endpoint. TML channels separately for each single ForCES endpoint.
skipping to change at page 22, line 39 skipping to change at page 23, 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.
Appendix B. Service Interface Appendix B. Suggested 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
 End of changes. 30 change blocks. 
72 lines changed or deleted 85 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/