draft-ietf-forces-protocol-21.txt   draft-ietf-forces-protocol-22.txt 
Network Working Group A. Doria (Ed.) Network Working Group A. Doria (Ed.)
Internet-Draft Lulea University of Technology Internet-Draft Lulea University of Technology
Intended status: Standards Track R. Haas (Ed.) Intended status: Standards Track R. Haas (Ed.)
Expires: August 7, 2009 IBM Expires: September 3, 2009 IBM
J. Hadi Salim (Ed.) J. Hadi Salim (Ed.)
Znyx Znyx
H. Khosravi (Ed.) H. Khosravi (Ed.)
Intel Intel
W. M. Wang (Ed.) W. M. Wang (Ed.)
Zhejiang Gongshang University Zhejiang Gongshang University
February 3, 2009 March 2, 2009
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-21.txt draft-ietf-forces-protocol-22.txt
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 40 skipping to change at page 1, line 40
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 August 7, 2009. This Internet-Draft will expire on September 3, 2009.
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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document specifies the Forwarding and Control Element Separation This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications (ForCES) protocol. ForCES protocol is used for communications
between Control Elements(CEs) and Forwarding Elements (FEs) in a between Control Elements(CEs) and Forwarding Elements (FEs) in a
ForCES Network Element (ForCES NE). This specification is intended ForCES Network Element (ForCES NE). This specification is intended
to meet the ForCES protocol requirements defined in RFC3654. Besides to meet the ForCES protocol requirements defined in RFC3654. Besides
the ForCES protocol, this specification also defines the requirements the ForCES protocol, this specification also defines the requirements
for the Transport Mapping Layer (TML). for the Transport Mapping Layer (TML).
skipping to change at page 4, line 44 skipping to change at page 4, line 44
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18
4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20
4.3.1. Transactions, Atomicity, Execution and Responses . . 20 4.3.1. Transactions, Atomicity, Execution and Responses . . 20
4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26
4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27
4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27
4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28
4.4.1. Association Setup State . . . . . . . . . . . . . . . 28 4.4.1. Association Setup State . . . . . . . . . . . . . . . 28
4.4.2. Association Established state or Steady State . . . . 29 4.4.2. Association Established state or Steady State . . . . 29
5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32
5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 34 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 35
6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 35 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 36
6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 40 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 41
6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 41 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 42
6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 41 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 42
6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.4. Important Protocol encapsulations . . . . . . . . . . . . 42 6.4. Important Protocol encapsulations . . . . . . . . . . . . 43
6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 42 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 43
6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 43 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 44
6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 43 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 44
6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 43 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 44
7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 45 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 46
7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 49 7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 50
7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 49 7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 50
7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 49 7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 50
7.1.3. Relation of operational flags with global message 7.1.3. Relation of operational flags with global message
flags . . . . . . . . . . . . . . . . . . . . . . . . 50 flags . . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.4. Content Path Selection . . . . . . . . . . . . . . . 50 7.1.4. Content Path Selection . . . . . . . . . . . . . . . 51
7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 50 7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 51
7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 51 7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 52
7.1.7. RESULT TLV . . . . . . . . . . . . . . . . . . . . . 53 7.1.7. RESULT TLV . . . . . . . . . . . . . . . . . . . . . 54
7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 56 7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 57
7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 57 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 58
7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 58 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 59
7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 61 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 62
7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 62 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 63
7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 65 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 66
7.4. Semantics of Message Direction . . . . . . . . . . . . . 65 7.4. Semantics of Message Direction . . . . . . . . . . . . . 66
7.5. Association Messages . . . . . . . . . . . . . . . . . . 66 7.5. Association Messages . . . . . . . . . . . . . . . . . . 67
7.5.1. Association Setup Message . . . . . . . . . . . . . . 66 7.5.1. Association Setup Message . . . . . . . . . . . . . . 67
7.5.2. Association Setup Response Message . . . . . . . . . 68 7.5.2. Association Setup Response Message . . . . . . . . . 69
7.5.3. Association Teardown Message . . . . . . . . . . . . 69 7.5.3. Association Teardown Message . . . . . . . . . . . . 70
7.6. Configuration Messages . . . . . . . . . . . . . . . . . 71 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 72
7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 71 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 72
7.6.2. Config Response Message . . . . . . . . . . . . . . . 73 7.6.2. Config Response Message . . . . . . . . . . . . . . . 74
7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 75 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 76
7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 75 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 76
7.7.2. Query Response Message . . . . . . . . . . . . . . . 77 7.7.2. Query Response Message . . . . . . . . . . . . . . . 78
7.8. Event Notification Message . . . . . . . . . . . . . . . 79 7.8. Event Notification Message . . . . . . . . . . . . . . . 80
7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 81 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 82
7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 84 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 85
8. High Availability Support . . . . . . . . . . . . . . . . . . 86 8. High Availability Support . . . . . . . . . . . . . . . . . . 87
8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 86 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 87
8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 89 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 90
9. Security Considerations . . . . . . . . . . . . . . . . . . . 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 91
9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 90 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 91
9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 91 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 92
9.1.2. Message Authentication . . . . . . . . . . . . . . . 91 9.1.2. Message Authentication . . . . . . . . . . . . . . . 92
9.2. ForCES PL and TML security service . . . . . . . . . . . 91 9.2. ForCES PL and TML security service . . . . . . . . . . . 92
9.2.1. Endpoint authentication service . . . . . . . . . . . 91 9.2.1. Endpoint authentication service . . . . . . . . . . . 92
9.2.2. Message authentication service . . . . . . . . . . . 92 9.2.2. Message authentication service . . . . . . . . . . . 93
9.2.3. Confidentiality service . . . . . . . . . . . . . . . 92 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 93
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 94
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 94 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 95
11.1. Normative References . . . . . . . . . . . . . . . . . . 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 95
11.2. Informational References . . . . . . . . . . . . . . . . 94 11.2. Informational References . . . . . . . . . . . . . . . . 95
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 95 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 96
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 95 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 96
A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 96 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 97
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 97 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 98
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 97 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 98
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 97 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 98
A.6. Association Setup Response . . . . . . . . . . . . . . . 98 A.6. Association Setup Response . . . . . . . . . . . . . . . 99
A.7. Association Teardown Message . . . . . . . . . . . . . . 99 A.7. Association Teardown Message . . . . . . . . . . . . . . 100
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 100 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 101
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 105 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 106
B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 105 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 106
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 106 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 107
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 110 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 111
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 126
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Other Notation 1.2. Other Notation
skipping to change at page 32, line 7 skipping to change at page 32, line 7
communication communication
Note that the sequence of messages shown in the figure serve only as Note that the sequence of messages shown in the figure serve only as
examples and the message exchange sequences could be different from examples and the message exchange sequences could be different from
what is shown in the figure. Also, note that the protocol scenarios what is shown in the figure. Also, note that the protocol scenarios
described in this section do not include all the different message described in this section do not include all the different message
exchanges that would take place during failover. That is described exchanges that would take place during failover. That is described
in the HA section (Section 8) . in the HA section (Section 8) .
5. TML Requirements 5. TML Requirements
The requirements below are expected to be delivered by the TML. This The requirements below are expected to be met by the TML. This text
text does not define how such mechanisms are delivered. As an does not define how such mechanisms are delivered. As an example,
example they could be defined to be delivered via hardware or between the mechanisms to meet the requirements could be defined to be
2 or more TML processes on different CEs or FEs in protocol level delivered via hardware or between 2 or more TML software processes on
schemes. different CEs or FEs in protocol level schemes.
Each TML MUST describe how it contributes to achieving the listed Each TML MUST describe how it contributes to achieving the listed
ForCES requirements. If for any reason a TML does not provide a ForCES requirements. If for any reason a TML does not provide a
service listed below a justification needs to be provided. service listed below a justification needs to be provided.
Implementations that support the ForCES Protocol Specification MUST Implementations that support the ForCES Protocol Specification MUST
IMPLEMENT [SCTP-TML]. Note that additional TMLs might be specified IMPLEMENT [SCTP-TML]. Note that additional TMLs might be specified
in the future, and if a new TML defined in the future that meets the in the future, and if a new TML defined in the future that meets the
requirements listed here proves to be better, then the MUST IMPLEMENT requirements listed here proves to be better, then the MUST IMPLEMENT
TML may redefined. TML may redefined.
1. Reliability 1. Reliability
As defined by [RFC3654], section 6 requirement #6.
Various ForCES messages will require varying degrees of reliable
delivery via the TML. It is the TML's responsibility to provide
these shades of reliability and describe how the different ForCES
messages map to reliability.
The most common level of reliability is what we refer to as
strict or robust reliability in which we mean: no losses,
corruption, or re-ordering of information being transported while
ensuring message delivery in a timely fashion.
Payloads such as configuration from a CE and its response from an
FE are mission critical and must be delivered in a robust
reliable fashion. Thus, for information of this sort, the TML
MUST either provide built-in protocol mechanisms or use a
reliable transport protocol for achieving robust/strict
reliability.
Some information or payloads, such as redirected packets or
packet sampling, may not require robust reliability (can tolerate
some degree of losses). For information of this sort, the TML
could define to use a mechanism that is not strictly reliable
(while conforming to other TML requirements such as congestion
control).
Some information or payloads, such as heartbeat packets that may
prefer timeliness over reliable delivery. For information of
this sort, the TML could define to use a mechanism that is not
strictly reliable (while conforming to other TML requirements
such as congestion control).
2. Security 2. Security
TML provides security services to the ForCES PL. Because a TML provides security services to the ForCES PL. Because a
ForCES PL is used to operate an NE, attacks designed to confuse, ForCES PL is used to operate an NE, attacks designed to confuse,
disable, or take information from a ForCES-based NE may be seen disable, or take information from a ForCES-based NE may be seen
as a prime objective during a network attack. as a prime objective during a network attack.
An attacker in a position to inject false messages into a PL An attacker in a position to inject false messages into a PL
stream can either affect the FE's treatment of the data path stream can either affect the FE's treatment of the data path
(example by falsifying control data reported as coming from the (example by falsifying control data reported as coming from the
skipping to change at page 34, line 5 skipping to change at page 34, line 34
does not mean that the underlying TML MUST be capable of does not mean that the underlying TML MUST be capable of
providing up to 8 actual priority levels. In the event that the providing up to 8 actual priority levels. In the event that the
underlying TML layer does not have support for 8 priority levels, underlying TML layer does not have support for 8 priority levels,
the supported priority levels should be divided between the the supported priority levels should be divided between the
available TML priority levels. For example, if the TML only available TML priority levels. For example, if the TML only
supports 2 priority levels, the 0-3 could go in one TML priority supports 2 priority levels, the 0-3 could go in one TML priority
level, while 4-7 could go in the other. level, while 4-7 could go in the other.
The TML MUST NOT reorder config packets with the same priority. The TML MUST NOT reorder config packets with the same priority.
8. Protection against DoS attacks 8. Node Overload Prevention
As described in RFC 3654, section 6
The TML MUST define mechanisms it uses to help prevent node
overload.
Overload results in starvation of node compute cycles and/or
bandwidth resources which reduces the operational capacity of a
ForCES NE. NE node overload could be deliberately instigated by
a hostile node to attack a ForCES NE and create a denial of
service. It could also be created by a variety of other reasons
such as large control protocol updates (eg BGP flaps) which
consequently cause a high frequency of CE to FE table updates, HA
failovers or component failures which migrate an FE or CE load
overwhelming the new CE or FE, etc. Although the environment
under which SIP and ForCES operate are different, [RFC5390]
provides a good guide to generic node requirements one needs to
guard for.
A ForCES node CPU may be overwhelmed because the incoming packet
rate is higher than it can keep up with - in such a case a nodes
transport queues grow and transport congestion subsequently
follows. A ForCES node CPU may also be adversely overloaded with
very few packets i.e no transport congestion at all (eg a in a
DOS attack against a table hashing algorithmn which overflows the
table and/or keeps the CPU busy so it does not process other
tasks) The TML node-overload solution specified MUST address both
types of node overload scenarios.
5.1. TML Parameterization 5.1. 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 52, line 9 skipping to change at page 53, line 9
7.1.6. OPER-TLV 7.1.6. OPER-TLV
The OPER-TLV is a place holder in the grammar for TLVs that define The OPER-TLV is a place holder in the grammar for TLVs that define
operations. The different types are defined in Table 3, below. operations. The different types are defined in Table 3, below.
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments | | OPER-TLV | TLV | Comments |
| | "Type" | | | | "Type" | |
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or add | | SET | 0x0001 | From CE to FE. Used to create or |
| | | or update attributes | | | | add or update attributes |
| | | | | | | |
| SET-PROP | 0x0002 | From CE to FE. Used to create or add | | SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | or update attribute properties | | | | add or update attribute properties |
| | | | | | | |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET | | | | response of a SET |
| | | | | | | |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP | | | | response of a SET-PROP |
| | | | | | | |
| DEL | 0x0005 | From CE to FE. Used to delete or | | DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an attribute | | | | remove an attribute |
| | | | | | | |
skipping to change at page 94, line 24 skipping to change at page 95, line 24
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000. RFC 2914, September 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5390] Rosenberg, J., "Requirements for Management of Overload in
the Session Initiation Protocol", RFC 5390, December 2008.
[SCTP-TML] [SCTP-TML]
Hadi Salim, J. and K. Ogawa, "SCTP based TML (Transport Hadi Salim, J. and K. Ogawa, "SCTP based TML (Transport
Mapping Layer) for ForCES protocol", internet Mapping Layer) for ForCES protocol", internet
draft draft-ietf-forces-sctptml, work in progress, draft draft-ietf-forces-sctptml, work in progress,
Feb. 2009. Feb. 2009.
11.2. Informational References 11.2. Informational References
[2PCREF] Gray, J., "Notes on database operating systems. In [2PCREF] Gray, J., "Notes on database operating systems. In
Operating Systems: An Advanced Course. Lecture Notes in Operating Systems: An Advanced Course. Lecture Notes in
 End of changes. 13 change blocks. 
91 lines changed or deleted 147 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/