draft-ietf-forces-protocol-20.txt   draft-ietf-forces-protocol-21.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
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 February 3, 2009
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-20.txt draft-ietf-forces-protocol-21.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 8, line 40 skipping to change at page 8, line 40
Section 3 provides a glossary of terminology used in the Section 3 provides a glossary of terminology used in the
specification. specification.
Section 4 provides an overview of the protocol, including a Section 4 provides an overview of the protocol, including a
discussion on the protocol framework, descriptions of the Protocol discussion on the protocol framework, descriptions of the Protocol
Layer (PL) and a Transport Mapping Layer (TML), as well as of the Layer (PL) and a Transport Mapping Layer (TML), as well as of the
ForCES protocol mechanisms. Section 4.4 describes several Protocol ForCES protocol mechanisms. Section 4.4 describes several Protocol
scenarios and includes message exchange descriptions. scenarios and includes message exchange descriptions.
While this document does not define the TML, Section 5 details the While this document does not define the TML, Section 5 details the
services that a TML must provide (TML requirements). services that a TML MUST provide (TML requirements).
The ForCES protocol defines a common header for all protocol The ForCES protocol defines a common header for all protocol
messages. The header is defined in Section 6.1, while the protocol messages. The header is defined in Section 6.1, while the protocol
messages are defined in Section 7. messages are defined in Section 7.
Section 8 describes the protocol support for high availability Section 8 describes the protocol support for high availability
mechanisms including redundancy and fail over. mechanisms including redundancy and fail over.
Section 9 defines the security mechanisms provided by the PL and TML. Section 9 defines the security mechanisms provided by the PL and TML.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
properties [ACID], defined as: properties [ACID], defined as:
Atomicity: In a transaction involving two or more discrete pieces Atomicity: In a transaction involving two or more discrete pieces
of information, either all of the pieces are committed of information, either all of the pieces are committed
or none are. or none are.
Consistency: A transaction either creates a new and valid state of Consistency: A transaction either creates a new and valid state of
data, or, if any failure occurs, returns all data to the data, or, if any failure occurs, returns all data to the
state it was in before the transaction was started. state it was in before the transaction was started.
Isolation: A transaction in process and not yet committed must Isolation: A transaction in process and not yet committed MUST
remain isolated from any other transaction. remain isolated from any other transaction.
Durability: Committed data is saved by the system such that, even in Durability: Committed data is saved by the system such that, even in
the event of a failure and a system restart, the data is the event of a failure and a system restart, the data is
available in its correct state. available in its correct state.
There are cases where the CE knows exact memory and implementation There are cases where the CE knows exact memory and implementation
details of the FE such as in the case of an FE-CE pair from the same details of the FE such as in the case of an FE-CE pair from the same
vendor where the FE-CE pair is tightly coupled. In such a case, the vendor where the FE-CE pair is tightly coupled. In such a case, the
transactional operations may be simplified further by extra transactional operations may be simplified further by extra
computation at the CE. This view is not discussed further other than computation at the CE. This view is not discussed further other than
to mention that it is not disallowed. to mention that it is not disallowed.
As defined above, a transaction is always atomic and MAY be As defined above, a transaction is always atomic and MAY be
a. Within an FE alone a. Within an FE alone
Example: updating multiple tables that are dependent on each Example: updating multiple tables that are dependent on each
other. If updating one fails, then any that were already updated other. If updating one fails, then any that were already updated
must be undone. MUST be undone.
b. Distributed across the NE b. Distributed across the NE
Example: updating table(s) that are inter-dependent across Example: updating table(s) that are inter-dependent across
several FEs (such as L3 forwarding related tables). several FEs (such as L3 forwarding related tables).
4.3.1.2.2. Transaction Protocol 4.3.1.2.2. Transaction Protocol
By use of the execute mode, as defined in Section 4.3.1.1, the By use of the execute mode, as defined in Section 4.3.1.1, the
protocol has provided a mechanism for transactional operations within protocol has provided a mechanism for transactional operations within
one stand-alone message. The 'execute-all-or-none' mode can meet the one stand-alone message. The 'execute-all-or-none' mode can meet the
skipping to change at page 22, line 47 skipping to change at page 22, line 47
For transactional operations of multiple messages within one FE or For transactional operations of multiple messages within one FE or
across FEs, a classical transactional protocol known as Two Phase across FEs, a classical transactional protocol known as Two Phase
Commit (2PC) [2PCREF] is supported by the protocol to achieve the Commit (2PC) [2PCREF] is supported by the protocol to achieve the
transactional operations utilizing Config messages (Section 7.6.1). transactional operations utilizing Config messages (Section 7.6.1).
The COMMIT and TRCOMP operations in conjunction with the AT and the The COMMIT and TRCOMP operations in conjunction with the AT and the
TP flags in Common Header (Section 6.1) are provided for 2PC-based TP flags in Common Header (Section 6.1) are provided for 2PC-based
transactional operations spanning multiple messages. transactional operations spanning multiple messages.
The AT flag, when set, indicates this message belongs to an Atomic The AT flag, when set, indicates this message belongs to an Atomic
Transaction. All messages for a transaction operation must have the Transaction. All messages for a transaction operation MUST have the
AT flag set. If not set, it means the message is a stand-alone AT flag set. If not set, it means the message is a stand-alone
message and does not participate in any transaction operation that message and does not participate in any transaction operation that
spans multiple messages. spans multiple messages.
The TP flag indicates the Transaction Phase this message belongs to. The TP flag indicates the Transaction Phase this message belongs to.
There are four (4) possible phases for an transactional operation There are four (4) possible phases for an transactional operation
known as: known as:
SOT (Start of Transaction) SOT (Start of Transaction)
skipping to change at page 27, line 35 skipping to change at page 27, line 35
An HB can be sourced by either the CE or FE. When sourced by the CE, An HB can be sourced by either the CE or FE. When sourced by the CE,
a response can be requested (similar to the ICMP ping protocol). The a response can be requested (similar to the ICMP ping protocol). The
FE can only generate HBs in the case of being configured to do so by FE can only generate HBs in the case of being configured to do so by
the CE. Refer to Section 7.3.1 and Section 7.10 for details. the CE. Refer to Section 7.3.1 and Section 7.10 for details.
4.3.4. FE Object and FE Protocol LFBs 4.3.4. FE Object and FE Protocol LFBs
All PL messages operate on LFB constructs, as this provides more All PL messages operate on LFB constructs, as this provides more
flexibility for future enhancements. This means that maintenance and flexibility for future enhancements. This means that maintenance and
configurability of FEs, NE, as well as the ForCES protocol itself configurability of FEs, NE, as well as the ForCES protocol itself
must be expressed in terms of this LFB architecture. For this reason MUST be expressed in terms of this LFB architecture. For this reason
special LFBs are created to accommodate this need. special LFBs are created to accommodate this need.
In addition, this shows how the ForCES protocol itself can be In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc. control functions such as IP forwarding, filtering, etc.
To achieve this, the following specialized LFBs are introduced: To achieve this, the following specialized LFBs are introduced:
o FE Protocol LFB which is used to control the ForCES protocol. o FE Protocol LFB which is used to control the ForCES protocol.
skipping to change at page 32, line 13 skipping to change at page 32, line 13
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 delivered by the TML. This
text does not define how such mechanisms are delivered. As an text does not define how such mechanisms are delivered. As an
example they could be defined to be delivered via hardware or between example they could be defined to be delivered via hardware or between
2 or more TML processes on different CEs or FEs in protocol level 2 or more TML processes on different CEs or FEs in protocol level
schemes. 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
skipping to change at page 32, line 44 skipping to change at page 32, line 44
(example by falsifying control data reported as coming from the (example by falsifying control data reported as coming from the
CE), or the CE itself (by modifying events or responses reported CE), or the CE itself (by modifying events or responses reported
as coming from the FE); for this reason, CE and FE node as coming from the FE); for this reason, CE and FE node
authentication and TML Message authentication is important. authentication and TML Message authentication is important.
The PL messages may also contain information of value to an The PL messages may also contain information of value to an
attacker, including information about the configuration of the attacker, including information about the configuration of the
network, encryption keys and other sensitive control data, so network, encryption keys and other sensitive control data, so
care must be taken to confine their visibility to authorized user care must be taken to confine their visibility to authorized user
* The TML must provide a mechanism to authenticate ForCES CEs * The TML MUST provide a mechanism to authenticate ForCES CEs
and FEs in order to prevent the participation of unauthorized and FEs in order to prevent the participation of unauthorized
CEs and unauthorized FEs in the control and data path CEs and unauthorized FEs in the control and data path
processing of a ForCES NE. processing of a ForCES NE.
* The TML SHOULD provide a mechanism to ensure message * The TML SHOULD provide a mechanism to ensure message
authentication of PL data transferred from the CE to FE (and authentication of PL data transferred from the CE to FE (and
vice-versa) in order to prevent the injection of incorrect vice-versa) in order to prevent the injection of incorrect
data into PL messages. data into PL messages.
* The TML SHOULD provide a mechanism to ensure the * The TML SHOULD provide a mechanism to ensure the
skipping to change at page 33, line 26 skipping to change at page 33, line 26
the FE or CE side. the FE or CE side.
4. Uni/multi/broadcast addressing/delivery, if any 4. Uni/multi/broadcast addressing/delivery, if any
If there is any mapping between PL and TML level uni/multi/ If there is any mapping between PL and TML level uni/multi/
broadcast addressing it needs to be defined. broadcast addressing it needs to be defined.
5. HA decisions 5. HA decisions
It is expected that availability of transport links is the TML's It is expected that availability of transport links is the TML's
responsibility. However, based upon its configuration, the PL responsibility. However, based upon its configuration, the PL
may wish to participate in link failover schemes and therefore may wish to participate in link failover schemes and therefore
the TML must support this capability. the TML MUST support this capability.
Please refer to Section 8 for details. Please refer to Section 8 for details.
6. Encapsulations used 6. Encapsulations used
Different types of TMLs will encapsulate the PL messages on Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the different types of headers. The TML needs to specify the
encapsulation used. encapsulation used.
7. Prioritization 7. Prioritization
It is expected that the TML will be able to handle up to 8 It is expected that the TML will be able to handle up to 8
priority levels needed by the PL and will provide preferential priority levels needed by the PL and will provide preferential
skipping to change at page 55, line 14 skipping to change at page 55, line 14
| E_EXISTS | 0x0A | The specified object | | E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot | | | | exists but it cannot |
| | | exist for the operation | | | | exist for the operation |
| | | to succeed (e.g., | | | | to succeed (e.g., |
| | | attempt to add an | | | | attempt to add an |
| | | existing LFB instance | | | | existing LFB instance |
| | | or array subscript). | | | | or array subscript). |
| | | | | | | |
| E_NOT_FOUND | 0x0B | The specified object | | E_NOT_FOUND | 0x0B | The specified object |
| | | does not exist but it | | | | does not exist but it |
| | | must exist for the | | | | MUST exist for the |
| | | operation to succeed | | | | operation to succeed |
| | | (e.g., attempt to | | | | (e.g., attempt to |
| | | delete a non-existing | | | | delete a non-existing |
| | | LFB instance or array | | | | LFB instance or array |
| | | subscript). | | | | subscript). |
| | | | | | | |
| E_READ_ONLY | 0x0C | Attempt to modify a | | E_READ_ONLY | 0x0C | Attempt to modify a |
| | | read-only value. | | | | read-only value. |
| | | | | | | |
| E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an |
skipping to change at page 62, line 11 skipping to change at page 62, line 11
ForCES protocol and to interact with FEs and CEs: ForCES protocol and to interact with FEs and CEs:
o FE Protocol LFB o FE Protocol LFB
o FE Object LFB o FE Object LFB
Although these LFBs have the same form and interface as other LFBs, Although these LFBs have the same form and interface as other LFBs,
they are special in many respects. They have fixed well-known LFB they are special in many respects. They have fixed well-known LFB
Class and Instance IDs. They are statically defined (no dynamic Class and Instance IDs. They are statically defined (no dynamic
instantiation allowed) and their status cannot be changed by the instantiation allowed) and their status cannot be changed by the
protocol: any operation to change the state of such LFBs (for protocol: any operation to change the state of such LFBs (for
instance, in order to disable the LFB) must result in an error. instance, in order to disable the LFB) MUST result in an error.
Moreover, these LFBs must exist before the first ForCES message can Moreover, these LFBs MUST exist before the first ForCES message can
be sent or received. All attributes in these LFBs must have pre- be sent or received. All attributes in these LFBs MUST have pre-
defined default values. Finally, these LFBs do not have input or defined default values. Finally, these LFBs do not have input or
output ports and do not integrate into the intra-FE LFB topology. output ports and do not integrate into the intra-FE LFB topology.
7.3.1. FE Protocol LFB 7.3.1. FE Protocol LFB
The FE Protocol LFB is a logical entity in each FE that is used to The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB Class ID is control the ForCES protocol. The FE Protocol LFB Class ID is
assigned the value 0x2. The FE Protocol LFB Instance ID is assigned assigned the value 0x2. The FE Protocol LFB Instance ID is assigned
the value 0x1. There MUST be one and only one instance of the FE the value 0x1. There MUST be one and only one instance of the FE
Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB in an FE. The values of the attributes in the FE
skipping to change at page 64, line 5 skipping to change at page 64, line 5
the FE should behave so that the CE can deduce its liveness. The the FE should behave so that the CE can deduce its liveness. The
policy values and the meanings are: policy values and the meanings are:
o 0 (default) - The FE should not generate any Heartbeat messages. o 0 (default) - The FE should not generate any Heartbeat messages.
In this scenario, the CE is responsible for checking FE liveness In this scenario, the CE is responsible for checking FE liveness
by setting the PL header ACK flag of the message it sends to by setting the PL header ACK flag of the message it sends to
AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat
Request Message. Refer to Section 7.10 and Section 4.3.3 for Request Message. Refer to Section 7.10 and Section 4.3.3 for
details. details.
o 1 - This policy specifies that FE must actively send a Heartbeat o 1 - This policy specifies that FE MUST actively send a Heartbeat
Message if it reaches the time interval assigned by the FE HI as Message if it reaches the time interval assigned by the FE HI as
long as no other messages were sent from FE to CE during that long as no other messages were sent from FE to CE during that
interval as described in Section 4.3.3. interval as described in Section 4.3.3.
o Others - Reserved. o Others - Reserved.
7.3.1.1.2.7. FEHI 7.3.1.1.2.7. FEHI
FE Heartbeat Interval (FE HI) - The time interval the FE should use FE Heartbeat Interval (FE HI) - The time interval the FE should use
to send HB as long as no other messages were sent from FE to CE to send HB as long as no other messages were sent from FE to CE
skipping to change at page 94, line 24 skipping to change at page 94, 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.
[SCTP-TML] Hadi Salim, J. and K. Ogawa, "SCTP based TML (Transport [SCTP-TML]
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
Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", Computer Science, Vol. 60, pp. 394-481, Springer-Verlag",
1978. 1978.
skipping to change at page 96, line 6 skipping to change at page 96, line 6
0x05 EventNotification 0x05 EventNotification
0x06 PacketRedirect 0x06 PacketRedirect
0x07 - 0x0E Reserved 0x07 - 0x0E Reserved
0x0F Hearbeat 0x0F Hearbeat
0x11 AssociationSetupRepsonse 0x11 AssociationSetupRepsonse
0x12 Reserved 0x12 Reserved
0x13 ConfigRepsonse 0x13 ConfigRepsonse
0x14 QueryResponse 0x14 QueryResponse
Message Types 0x20 - 0x7F Message Types 0x20 - 0x7F
Message Types in this range are Specification Required [RFC5226] Message Types in this range are Specification Required [RFC5226]
Message Types using this range must be documented in an RFC or Message Types using this range MUST be documented in an RFC or
other permanent and readily available reference. other permanent and readily available reference.
Message Types 0x80 - 0xFF Message Types 0x80 - 0xFF
Message Types in this range are reserved for vendor private Message Types in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA extensions and are the responsibility of individual vendors. IANA
management of this range of the Message Type Name Space is management of this range of the Message Type Name Space is
unnecessary. unnecessary.
A.2. Operation Selection A.2. Operation Selection
skipping to change at page 96, line 43 skipping to change at page 96, line 43
0x0007 GET 0x0007 GET
0x0008 GET-PROP 0x0008 GET-PROP
0x0009 GET-RESPONSE 0x0009 GET-RESPONSE
0x000A GET-PROP-RESPONSE 0x000A GET-PROP-RESPONSE
0x000B REPORT 0x000B REPORT
0x000C COMMIT 0x000C COMMIT
0x000D COMMIT-RESPONSE 0x000D COMMIT-RESPONSE
0x000E TRCOMP 0x000E TRCOMP
OPER-TLV Type 0x0100-0x7FFF OPER-TLV Type 0x0100-0x7FFF
OPER-TLV Types using this range must be documented in an RFC or OPER-TLV Types using this range MUST be documented in an RFC or
other permanent and readily available reference. [RFC5226]. other permanent and readily available reference. [RFC5226].
OPER-TLV Type 0x8000-0xFFFF OPER-TLV Type 0x8000-0xFFFF
OPER-TLV Types in this range are reserved for vendor private OPER-TLV Types in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA extensions and are the responsibility of individual vendors. IANA
management of this range of the OPER-TLV Type Name Space is management of this range of the OPER-TLV Type Name Space is
unnecessary. unnecessary.
A.3. Header Flags A.3. Header Flags
skipping to change at page 97, line 36 skipping to change at page 97, line 36
0x1000 LFBselect-TLV 0x1000 LFBselect-TLV
0x0110 PATH-DATA-TLV 0x0110 PATH-DATA-TLV
0x0111 KEYINFO-TLV 0x0111 KEYINFO-TLV
0x0112 FULLDATA-TLV 0x0112 FULLDATA-TLV
0x0113 SPARSEDATA-TLV 0x0113 SPARSEDATA-TLV
0x0114 RESULT-TLV 0x0114 RESULT-TLV
0x0115 METADATA-TLV 0x0115 METADATA-TLV
0x0116 REDIRECTDATA-TLV 0x0116 REDIRECTDATA-TLV
TLV Type 0x0200-0x7FFF TLV Type 0x0200-0x7FFF
TLV Types using this range must be documented in an RFC or other TLV Types using this range MUST be documented in an RFC or other
permanent and readily available reference [RFC5226]. permanent and readily available reference [RFC5226].
TLV Type 0x8000-0xFFFF TLV Type 0x8000-0xFFFF
TLV Types in this range are reserved for vendor private extensions TLV Types in this range are reserved for vendor private extensions
and are the responsibility of individual vendors. IANA management and are the responsibility of individual vendors. IANA management
of this range of the TLV Type Name Space is unnecessary. of this range of the TLV Type Name Space is unnecessary.
A.5. Result-TLV Result Values A.5. Result-TLV Result Values
The RESULT-TLV RTesult Value is an 8 bit value. The RESULT-TLV RTesult Value is an 8 bit value.
skipping to change at page 99, line 6 skipping to change at page 99, line 6
Association Setup Responses in this range are allocated through an Association Setup Responses in this range are allocated through an
IETF consensus process [RFC5226]. IETF consensus process [RFC5226].
Values assigned by this specification: Values assigned by this specification:
0x0000 Success 0x0000 Success
0x0001 FE ID Invalid 0x0001 FE ID Invalid
0x0002 Permission Denied 0x0002 Permission Denied
Association Setup Response 0x0100-0x0FFF Association Setup Response 0x0100-0x0FFF
Association Setup Responses in this range are Specification Association Setup Responses in this range are Specification
Required [RFC5226] Values using this range must be documented in Required [RFC5226] Values using this range MUST be documented in
an RFC or other permanent and readily available reference an RFC or other permanent and readily available reference
[RFC5226]. [RFC5226].
Association Setup Response 0x1000-0xFFFFFFFFF Association Setup Response 0x1000-0xFFFFFFFFF
Association Setup Responses in this range are reserved for vendor Association Setup Responses in this range are reserved for vendor
private extensions and are the responsibility of individual private extensions and are the responsibility of individual
vendors. IANA management of this range of the Association Setup vendors. IANA management of this range of the Association Setup
Responses Name Space is unnecessary. Responses Name Space is unnecessary.
A.7. Association Teardown Message A.7. Association Teardown Message
skipping to change at page 99, line 38 skipping to change at page 99, line 38
0x00000000 Normal - Teardown by Administrator 0x00000000 Normal - Teardown by Administrator
0x00000001 Error - loss of heartbeats 0x00000001 Error - loss of heartbeats
0x00000002 Error - loss of bandwidth 0x00000002 Error - loss of bandwidth
0x00000003 Error - Out of Memory 0x00000003 Error - Out of Memory
0x00000004 Error - Application Crash 0x00000004 Error - Application Crash
0x000000FF Error - Unspecified 0x000000FF Error - Unspecified
Association Teardown Message 0x00010000-0x7FFFFFFF Association Teardown Message 0x00010000-0x7FFFFFFF
Association Teardown Messages in this range are Specification Association Teardown Messages in this range are Specification
Required [RFC5226] Association Teardown Messages using this range Required [RFC5226] Association Teardown Messages using this range
must be documented in an RFC or other permanent and readily MUST be documented in an RFC or other permanent and readily
available references. [RFC5226]. available references. [RFC5226].
Association Teardown Message 0x80000000-0xFFFFFFFFF Association Teardown Message 0x80000000-0xFFFFFFFFF
Association Teardown Messages in this range are reserved for Association Teardown Messages in this range are reserved for
vendor private extensions and are the responsibility of individual vendor private extensions and are the responsibility of individual
vendors. IANA management of this range of the Association vendors. IANA management of this range of the Association
Teardown Message Name Space is unnecessary. Teardown Message Name Space is unnecessary.
Appendix B. ForCES Protocol LFB schema Appendix B. ForCES Protocol LFB schema
 End of changes. 18 change blocks. 
20 lines changed or deleted 21 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/