draft-ietf-forces-protocol-14.txt   draft-ietf-forces-protocol-15.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: September 12, 2008 IBM Expires: February 26, 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
March 11, 2008 August 25, 2008
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-14.txt draft-ietf-forces-protocol-15.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
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 September 2, 2008. This Internet-Draft will expire on February 26, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang
(Zhejiang Gongshang University). Special acknowledgement goes to (Zhejiang Gongshang University). Special acknowledgement goes to
Joel Halpern who has done extensive editing in support of congruence Joel Halpern who has done extensive editing in support of congruence
between the model and this protocol specification. Without his between the model and this protocol specification. Without his
participation and persistence, this specification might never have participation and persistence, this specification might never have
been completed. been completed.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
1.1. Other Notation . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12
4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18
skipping to change at page 5, line 13 skipping to change at page 5, line 14
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92
A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 93 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 93
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 94 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 94
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 94 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 94
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 94 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 94
A.6. Association Setup Response . . . . . . . . . . . . . . . 95 A.6. Association Setup Response . . . . . . . . . . . . . . . 95
A.7. Association Teardown Message . . . . . . . . . . . . . . 96 A.7. Association Teardown Message . . . . . . . . . . . . . . 96
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 97 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 97
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 102 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 102
B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 103 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 102
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 104 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 103
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 108 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 107
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
Intellectual Property and Copyright Statements . . . . . . . . . 125 Intellectual Property and Copyright Statements . . . . . . . . . 124
1. Terminology and Conventions 1. Terminology and Conventions
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 1.1. Requirements Language
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC2119 [RFC2119].
1.1. Other Notation 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 [RFC2119].
1.2. Other Notation
In table Table 1 and table Table 2 the following notation is used to In table Table 1 and table Table 2 the following notation is used to
indicate multiplicity: indicate multiplicity:
(value)+ .... means "1 or more instance of value" (value)+ .... means "1 or more instance of value"
(value)* .... means "0 or more instance of value" (value)* .... means "0 or more instance of value"
2. Introduction 2. Introduction
skipping to change at page 16, line 44 skipping to change at page 16, line 44
Figure 4: The FE State Machine Figure 4: The FE State Machine
In the mandated case, once associated, the FE may forward packets In the mandated case, once associated, the FE may forward packets
depending on the configuration of its specific LFBs. An FE which is depending on the configuration of its specific LFBs. An FE which is
associated to a CE will continue sending packets until it receives an associated to a CE will continue sending packets until it receives an
Association teardown message or until it loses association. An Association teardown message or until it loses association. An
unassociated FE MAY continue sending packets when it is capable high unassociated FE MAY continue sending packets when it is capable high
availability. The extra details are explained in Section 8 and not availability. The extra details are explained in Section 8 and not
discussed here to allow for a clear explanation of the basics. discussed here to allow for a clear explanation of the basics.
The CE configures FE state transitions by means of the FE Object LFB, The FE state transitions are controlled by means of the FE Object LFB
which is defined in [FE-MODEL] and also explained in Section 7.3.2. FEState component, which is defined in [FE-MODEL] and also explained
In the FE Object LFB, FE state is defined as an attribute of the LFB, in Section 7.3.2.
and CE configuration of the FE state equals CE configuration of this
attribute. Note that even in the FE DOWN state, the FE is
associated.
The FE stays in the DOWN state until it is explicitly configured by The FE initializes in the FEState OperDisable. When the FE is ready
the CE to transition to the UP state via an FE Object admin action. to process packets in the data path it transitions itself to the
This must be done before configuring any other LFBs that affect OperEnable state.
packet forwarding. The typical setup will bring up the FE to the UP
state on association.
The FE transitions from the UP state to the DOWN state when it The CE may decide to pause the FE after it already came up as
receives an FEObject Admin Down action. when it loses its association OperEnable. It does this by setting the FEState to AdminDisable.
with the CE it may go into the pre-association phase depending on the The FE stays in the AdminDisable state until it is explicitly
programmed policy. For the FE to properly complete the transition to configured by the CE to transition to the OperEnable.
the DOWN state, it MUST stop Packet forwarding and this may impact
multiple LFBS. How this is achieved is outside the scope of this When the FE loses its association with the CE it may go into the pre-
specification. association phase depending on the programmed policy. For the FE to
properly complete the transition to the AdminDisable state, it MUST
stop Packet forwarding and this may impact multiple LFBS. How this
is achieved is outside the scope of this specification.
4.2.1. Pre-association 4.2.1. Pre-association
The ForCES interface is configured during the pre-association phase. The ForCES interface is configured during the pre-association phase.
In a simple setup, the configuration is static and is read from a In a simple setup, the configuration is static and is read from a
saved configuration file. All the parameters for the association saved configuration file. All the parameters for the association
phase are well known after the pre-association phase is complete. A phase are well known after the pre-association phase is complete. A
protocol such as DHCP may be used to retrieve the configuration protocol such as DHCP may be used to retrieve the configuration
parameters instead of reading them from a static configuration file. parameters instead of reading them from a static configuration file.
Note, this will still be considered static pre-association. Dynamic Note, this will still be considered static pre-association. Dynamic
skipping to change at page 28, line 23 skipping to change at page 28, line 23
The associations among CEs and FEs are initiated via Association The associations among CEs and FEs are initiated via Association
setup message from the FE. If a setup request is granted by the CE, setup message from the FE. If a setup request is granted by the CE,
a successful setup response message is sent to the FE. If CEs and a successful setup response message is sent to the FE. If CEs and
FEs are operating in an insecure environment then the security FEs are operating in an insecure environment then the security
associations have to be established between them before any associations have to be established between them before any
association messages can be exchanged. The TML will take care of association messages can be exchanged. The TML will take care of
establishing any security associations. establishing any security associations.
This is typically followed by capability query, topology query, etc. This is typically followed by capability query, topology query, etc.
When the FE is ready to start forwarding data traffic, it sends an FE When the FE is ready to start processing the data path, it sets the
UP Event message to the CE. When the CE is ready, it responds by FEO FEState component to OperEnable (Refer to [FE-MODEL] for details)
enabling the FE by setting the FEStatus to Adminup (Refer to and reports it to the CE as such when it is first queried. Typically
[FE-MODEL] for details). This indicates to the FE to start the FE is expected to be ready to process the data path before it
forwarding data traffic. At this point the association establishment associates, but there maybe rare cases where it needs time do some
is complete. These sequences of messages are illustrated in the pre-processing - in such a case the FE will start in the OperDisable
Figure 8 below. state and when it is ready will transition to OperEnable state. An
example of an FE starting in the OperDisable then transitioning to
OperEnable is illustrated in Figure 8. The CE could at any time also
disable the FEs datapath operations by setting the FEState to
AdminDisable. The FE MUST NOT process packets during this state
unless the CE sets the state back to OperEnable. These sequences of
messages are illustrated in Figure 8 below.
FE PL CE PL FE PL CE PL
| | | |
| Asso Setup Req | | Asso Setup Req |
|---------------------->| |---------------------->|
| | | |
| Asso Setup Resp | | Asso Setup Resp |
|<----------------------| |<----------------------|
| | | |
skipping to change at page 29, line 26 skipping to change at page 29, line 26
| | | |
| LFBx Query Resp | | LFBx Query Resp |
|---------------------->| |---------------------->|
| | | |
| FEO Query (Topology) | | FEO Query (Topology) |
|<----------------------| |<----------------------|
| | | |
| FEO Query Resp | | FEO Query Resp |
|---------------------->| |---------------------->|
| | | |
| FEO UP Event | | FEO OperEnable Event |
|---------------------->| |---------------------->|
| | | |
| Config FEO Adminup | | Config FEO Adminup |
|<----------------------| |<----------------------|
| | | |
| FEO Config-Resp | | FEO Config-Resp |
|---------------------->| |---------------------->|
| | | |
Figure 8: Message exchange between CE and FE to establish an NE Figure 8: Message exchange between CE and FE to establish an NE
skipping to change at page 37, line 15 skipping to change at page 37, line 15
The ACK indicator flag is only used by the CE when sending a The ACK indicator flag is only used by the CE when sending a
Config Message (Section 7.6.1) or a HB message (Section 7.10) Config Message (Section 7.6.1) or a HB message (Section 7.10)
to indicate to the message receiver whether or not a response to indicate to the message receiver whether or not a response
is required by the sender. Note that for all other messages is required by the sender. Note that for all other messages
than the Config Message or the HB Message this flag MUST be than the Config Message or the HB Message this flag MUST be
ignored. ignored.
The flag values are defined as below: The flag values are defined as below:
'NoACK' (0b00) - to indicate that the message receiver 'NoACK' (0b00) - to indicate that the message receiver
MUST not send any response message back to this message MUST NOT send any response message back to this message
sender. sender.
'SuccessACK'(0b01) - to indicate the message receiver 'SuccessACK'(0b01) - to indicate the message receiver
MUST send a response message back only when the message MUST send a response message back only when the message
has been successfully processed by the receiver. has been successfully processed by the receiver.
'FailureACK'(0b10) - to indicate the message receiver 'FailureACK'(0b10) - to indicate the message receiver
MUST send a response message back only when there is MUST send a response message back only when there is
failure by the receiver in processing (executing) the failure by the receiver in processing (executing) the
message. In other words, if the message can be processed message. In other words, if the message can be processed
skipping to change at page 51, line 9 skipping to change at page 51, 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 | | SET | 0x0001 | From CE to FE. Used to create or add |
| | | add or update attributes | | | | or update attributes |
| | | | | | | |
| SET-PROP | 0x0002 | From CE to FE. Used to create or | | SET-PROP | 0x0002 | From CE to FE. Used to create or add |
| | | add or update attribute properties | | | | 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 56, line 8 skipping to change at page 56, line 8
ignored upon reception. ignored upon reception.
2. FULLDATA TLVs may be used at a particular path only if every 2. FULLDATA TLVs may be used at a particular path only if every
component at that path level is present. In example 1(c) of component at that path level is present. In example 1(c) of
Appendix C this concept is illustrated by the presence of all Appendix C this concept is illustrated by the presence of all
components of the structure S in the FULLDATA TLV encoding. This components of the structure S in the FULLDATA TLV encoding. This
requirement holds regardless of whether the fields are fixed or requirement holds regardless of whether the fields are fixed or
variable length, mandatory or optional. variable length, mandatory or optional.
* If a FULLDATA TLV is used, the encoder MUST lay out data for * If a FULLDATA TLV is used, the encoder MUST lay out data for
each component in the same order in which the data was defined each component in the same order in which the data was
in the LFB specification. This ensures the decoder is able to defined in the LFB specification. This ensures the decoder
retrieve the data. To use the example 1 again in Appendix C, is able to retrieve the data. To use the example 1 again in
this implies the encoder/decoder is assumed to have knowledge Appendix C, this implies the encoder/decoder is assumed to
of how structure S is laid out in the definition. have knowledge of how structure S is laid out in the
definition.
* In the case of a SPARSEDATA, it does not need to be ordered * In the case of a SPARSEDATA, it does not need to be ordered
since the "I" in the ILV uniquely identifies the component. since the "I" in the ILV uniquely identifies the component.
Examples 1(a) and 1(b) illustrate the power of SPARSEDATA Examples 1(a) and 1(b) illustrate the power of SPARSEDATA
encoding. encoding.
3. Inside a FULLDATA TLV 3. Inside a FULLDATA TLV
* The values for atomic, fixed-length fields are given without * The values for atomic, fixed-length fields are given without
any TLV or ILV encapsulation. any TLV or ILV encapsulation.
* The values for atomic, variable-length fields are given inside * The values for atomic, variable-length fields are given
FULLDATA TLVs. inside FULLDATA TLVs.
4. Inside a SPARSEDATA TLV 4. Inside a SPARSEDATA TLV
* The values for atomic fields may be given with ILVs (32-bit * The values for atomic fields may be given with ILVs (32-bit
index, 32-bit length) index, 32-bit length)
5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot
contain a FULLDATA. This is because it is hard to disambiguate contain a FULLDATA. This is because it is hard to disambiguate
ILV since an I is 32 bits and a T is 16 bits. ILV since an I is 32 bits and a T is 16 bits.
skipping to change at page 56, line 48 skipping to change at page 56, line 49
above. above.
7.1.9. SET and GET Relationship 7.1.9. SET and GET Relationship
It is expected that a GET-RESPONSE would satisfy the following: It is expected that a GET-RESPONSE would satisfy the following:
o It would have exactly the same path definitions as those sent in o It would have exactly the same path definitions as those sent in
the GET. The only difference being a GET-RESPONSE will contain the GET. The only difference being a GET-RESPONSE will contain
FULLDATA TLVs. FULLDATA TLVs.
o It should be possible to take the same GET-RESPONSE and convert it o It should be possible to take the same GET-RESPONSE and convert
to a SET successfully by merely changing the T in the operational it to a SET successfully by merely changing the T in the
TLV. operational TLV.
o There are exceptions to this rule: o There are exceptions to this rule:
1. When a KEY selector is used with a path in a GET operation, 1. When a KEY selector is used with a path in a GET operation,
that selector is not returned in the GET-RESPONSE; instead the that selector is not returned in the GET-RESPONSE; instead
cooked result is returned. Refer to the examples using KEYS the cooked result is returned. Refer to the examples using
to see this. KEYS to see this.
2. When dumping a whole table in a GET, the GET-RESPONSE that 2. When dumping a whole table in a GET, the GET-RESPONSE that
merely edits the T to be SET will end up overwriting the merely edits the T to be SET will end up overwriting the
table. table.
7.2. Protocol Encoding Visualization 7.2. Protocol Encoding Visualization
The figure below shows a general layout of the PL PDU. A main header The figure below shows a general layout of the PL PDU. A main header
is followed by one or more LFB selections each of which may contain is followed by one or more LFB selections each of which may contain
one or more operation. one or more operation.
skipping to change at page 61, line 21 skipping to change at page 61, line 21
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 0x1. 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
Protocol LFB have pre-defined default values that are specified here. Protocol LFB have pre-defined default values that are specified here.
Unless explicit changes are made to these values using Config Unless explicit changes are made to these values using Config
messages from the CE, these default values MUST be used for correct messages from the CE, these default values MUST be used for correct
operation of the protocol. operation of the protocol.
The formal definition of the FE Protocol Object LFB can be found in The formal definition of the FE Protocol Object LFB can be found in
Appendix B. Appendix B.
skipping to change at page 63, line 43 skipping to change at page 63, line 43
7.3.1.1.2.11. CEFailoverPolicy 7.3.1.1.2.11. CEFailoverPolicy
CE failover policy - This specifies the behavior of the FE when the CE failover policy - This specifies the behavior of the FE when the
association with the CE is lost. There is a very tight relation association with the CE is lost. There is a very tight relation
between CE failover policy and Section 7.3.1.1.2.8, between CE failover policy and Section 7.3.1.1.2.8,
Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an
association is lost, depending on configuration, one of the policies association is lost, depending on configuration, one of the policies
listed below is activated. listed below is activated.
o 0 (default) - FE should stop functioning immediately and o 0 (default) - FE should stop functioning immediately and
transition to FE DOWN. transition to FE OperDisable.
o 1 - The FE should continue running and do what it can even without o 1 - The FE should continue running and do what it can even without
an associated CE. This basically requires that the FE support CE an associated CE. This basically requires that the FE support CE
Graceful restart (and defines such support in its capabilities). Graceful restart (and defines such support in its capabilities).
If the CEFTI expires before the FE re-associates with either the If the CEFTI expires before the FE re-associates with either the
primary (Section 7.3.1.1.2.8) or one of possibly several backup primary (Section 7.3.1.1.2.8) or one of possibly several backup
CEs (Section 7.3.1.1.2.10), the FE will go operationally down. CEs (Section 7.3.1.1.2.10), the FE will go operationally down.
o Others - Reserved o Others - Reserved
skipping to change at page 89, line 11 skipping to change at page 89, line 11
associations for the FEs which are configured via the CEM. The CE associations for the FEs which are configured via the CEM. The CE
should validate the FE identifier before accepting the connections should validate the FE identifier before accepting the connections
during the pre-association phase. during the pre-association phase.
9.1.2. Message authentication 9.1.2. Message authentication
When a CE or FE initiates a message, the receiving endpoint MUST When a CE or FE initiates a message, the receiving endpoint MUST
validate the initiator of the message by checking the common header validate the initiator of the message by checking the common header
CE or FE identifiers. This will ensure proper protocol functioning. CE or FE identifiers. This will ensure proper protocol functioning.
This extra processing step is recommend even when underlying provides This extra processing step is recommend even when underlying provides
TLM layer security services exist. TML layer security services exist.
9.2. ForCES PL and TML security service 9.2. ForCES PL and TML security service
This section is applicable if an operator wishes to use the TML This section is applicable if an operator wishes to use the TML
security services. A ForCES TML MUST support one or more security security services. A ForCES TML MUST support one or more security
services such as endpoint authentication service, message services such as endpoint authentication service, message
authentication service, and confidentiality service, as part of TML authentication service, and confidentiality service, as part of TML
security layer functions. It is the responsibility of the operator security layer functions. It is the responsibility of the operator
to select an appropriate security service and configure security to select an appropriate security service and configure security
policies accordingly. The details of such configuration are outside policies accordingly. The details of such configuration are outside
skipping to change at page 91, line 17 skipping to change at page 91, line 17
11.1. Normative References 11.1. Normative References
[FE-MODEL] [FE-MODEL]
Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,
and S. Blake, "ForCES Forwarding Element Model", and S. Blake, "ForCES Forwarding Element Model",
Feb. 2005. Feb. 2005.
[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.
[RFC2434] 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 2434, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
October 1998. May 2008.
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.
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction- [ACID] Haerder, T. and A. Reuter, "Principles of Transaction-
Orientated Database Recovery", 1983. Orientated Database Recovery", 1983.
skipping to change at page 92, line 8 skipping to change at page 92, line 8
[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.
Appendix A. IANA Considerations Appendix A. IANA Considerations
Following the policies outlined in "Guidelines for Writing an IANA Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following Considerations Section in RFCs" (RFC 5226 [RFC5226]), the following
name spaces are defined in ForCES. name spaces are defined in ForCES.
o Message Type Name Space Section 7 o Message Type Name Space Section 7
o Operation Type Name Space Section 7.1.6 o Operation Type Name Space Section 7.1.6
o Header Flags Section 6.1 o Header Flags Section 6.1
o TLV Type Section 7 o TLV Type Section 7
skipping to change at page 92, line 35 skipping to change at page 92, line 35
o Reason: Association Teardown Message Section 7.5.3 o Reason: Association Teardown Message Section 7.5.3
A.1. Message Type Name Space A.1. Message Type Name Space
The Message Type is an 8 bit value. The following is the guideline The Message Type is an 8 bit value. The following is the guideline
for defining the Message Type namespace for defining the Message Type namespace
Message Types 0x00 - 0x0F Message Types 0x00 - 0x0F
Message Types in this range are part of the base ForCES Protocol. Message Types in this range are part of the base ForCES Protocol.
Message Types in this range are allocated through an IETF Message Types in this range are allocated through an IETF
consensus action. [RFC2434] consensus action. [RFC5226]
Values assigned by this specification: Values assigned by this specification:
0x00 Reserved 0x00 Reserved
0x01 AssociationSetup 0x01 AssociationSetup
0x02 AssociationTeardown 0x02 AssociationTeardown
0x03 Config 0x03 Config
0x04 Query 0x04 Query
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 [RFC2434] 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
The Operation Selection (OPER-TLV) name space is 16 bits long. The The Operation Selection (OPER-TLV) name space is 16 bits long. The
following is the guideline for managing the OPER-TLV Name Space. following is the guideline for managing the OPER-TLV Name Space.
OPER-TLV Type 0x0000-0x00FF OPER-TLV Type 0x0000-0x00FF
OPER-TLV Types in this range are allocated through an IETF OPER-TLV Types in this range are allocated through an IETF
consensus process. [RFC2434]. consensus process. [RFC5226].
Values assigned by this specification: Values assigned by this specification:
0x0000 Reserved 0x0000 Reserved
0x0001 SET 0x0001 SET
0x0002 SET-PROP 0x0002 SET-PROP
0x0003 SET-RESPONSE 0x0003 SET-RESPONSE
0x0004 SET-PROP-RESPONSE 0x0004 SET-PROP-RESPONSE
0x0005 DEL 0x0005 DEL
0x0006 DEL-RESPONSE 0x0006 DEL-RESPONSE
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. [RFC2434]. 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
The Header flag field is 32 bits long. Header flags are part of The Header flag field is 32 bits long. Header flags are part of
the ForCES base protocol. Header flags are allocated through an the ForCES base protocol. Header flags are allocated through an
IETF consensus action [RFC2434]. IETF consensus action [RFC5226].
A.4. TLV Type Name Space A.4. TLV Type Name Space
The TLV Type name space is 16 bits long. The following is the The TLV Type name space is 16 bits long. The following is the
guideline for managing the TLV Type Name Space. guideline for managing the TLV Type Name Space.
TLV Type 0x0000-0x00FF TLV Type 0x0000-0x00FF
TLV Types in this range are allocated through an IETF consensus TLV Types in this range are allocated through an IETF consensus
process. [RFC2434]. process. [RFC5226].
Values assigned by this specification: Values assigned by this specification:
0x0000 Reserved 0x0000 Reserved
0x0001 REDIRECT-TLV 0x0001 REDIRECT-TLV
0x0010 ASResult-TLV 0x0010 ASResult-TLV
0x0011 ASTreason-TLV 0x0011 ASTreason-TLV
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 [RFC2434]. 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 95, line 43 skipping to change at page 95, line 43
Assignment by Expert review. Assignment by Expert review.
A.6. Association Setup Response A.6. Association Setup Response
The Association Setup Response name space is 32 bits long. The The Association Setup Response name space is 32 bits long. The
following is the guideline for managing the Association Setup following is the guideline for managing the Association Setup
Response Name Space. Response Name Space.
Association Setup Response 0x0000-0x00FF Association Setup Response 0x0000-0x00FF
Association Setup Responses in this range are allocated through an Association Setup Responses in this range are allocated through an
IETF consensus process [RFC2434]. 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 [RFC2434] 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
[RFC2434]. [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
The Association Teardown Message name space is 32 bits long. The The Association Teardown Message name space is 32 bits long. The
following is the guideline for managing the Association Teardown following is the guideline for managing the Association Teardown
Message Name Space. Message Name Space.
Association Teardown Message 0x00000000-0x0000FFFF Association Teardown Message 0x00000000-0x0000FFFF
Association Teardown Messages in this range are allocated through Association Teardown Messages in this range are allocated through
an IETF consensus process [RFC2434]. an IETF consensus process [RFC5226].
Values assigned by this specification: Values assigned by this specification:
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 [RFC2434] 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. [RFC2434]. 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
The schema described below conforms to the LFB schema described in The schema described below conforms to the LFB schema described in
ForCES Model draft. [FE-MODEL] ForCES Model draft. [FE-MODEL]
Section 7.3.1 describes the details of the different components Section 7.3.1 describes the details of the different components
defined in this definition. defined in this definition.
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://ietf.org/forces/1.0/lfbmodel
provides="FEPO"> provides="FEPO">
<!-- XXX --> <!-- XXX -->
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>CEHBPolicyValues</name> <name>CEHBPolicyValues</name>
<synopsis> <synopsis>
The possible values of CE heartbeat policy The possible values of CE heartbeat policy
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
 End of changes. 40 change blocks. 
81 lines changed or deleted 92 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/