draft-ietf-forces-protocol-12.txt   draft-ietf-forces-protocol-13.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: May 21, 2008 IBM Expires: June 6, 2008 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
November 18, 2007 December 4, 2007
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-12.txt draft-ietf-forces-protocol-13.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 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 21, 2008. This Internet-Draft will expire on June 6, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 13 skipping to change at page 3, line 13
requirements for ForCES protocol. requirements for ForCES protocol.
Authors Authors
The participants in the ForCES Protocol Team, primary co-authors and The participants in the ForCES Protocol Team, primary co-authors and
co-editors, of this protocol specification, are: co-editors, of this protocol specification, are:
Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea
University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), University of Technology), Ram Gopal (Nokia), Robert Haas (IBM),
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). (Zhejiang Gongshang University). Special acknowledgement goes to
Joel Halpern whose has done extensive editing in support of
congruence between the model and this protocol specification.
Without his participation and persistence, this specification might
never have 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. 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
skipping to change at page 4, line 35 skipping to change at page 4, line 39
7.6.2. Config Response Message . . . . . . . . . . . . . . . 72 7.6.2. Config Response Message . . . . . . . . . . . . . . . 72
7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 74 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 74
7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 74 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 74
7.7.2. Query Response Message . . . . . . . . . . . . . . . 76 7.7.2. Query Response Message . . . . . . . . . . . . . . . 76
7.8. Event Notification Message . . . . . . . . . . . . . . . 78 7.8. Event Notification Message . . . . . . . . . . . . . . . 78
7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 80 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 80
7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82
8. High Availability Support . . . . . . . . . . . . . . . . . . 84 8. High Availability Support . . . . . . . . . . . . . . . . . . 84
8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84
8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87
9. Security Considerations . . . . . . . . . . . . . . . . . . . 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 89 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 88
9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 89 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 88
9.1.2. Message authentication . . . . . . . . . . . . . . . 90 9.1.2. Message authentication . . . . . . . . . . . . . . . 89
9.2. ForCES PL and TML security service . . . . . . . . . . . 90 9.2. ForCES PL and TML security service . . . . . . . . . . . 89
9.2.1. Endpoint authentication service . . . . . . . . . . . 90 9.2.1. Endpoint authentication service . . . . . . . . . . . 89
9.2.2. Message authentication service . . . . . . . . . . . 90 9.2.2. Message authentication service . . . . . . . . . . . 89
9.2.3. Confidentiality service . . . . . . . . . . . . . . . 90 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 89
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.1. Normative References . . . . . . . . . . . . . . . . . . 92 11.1. Normative References . . . . . . . . . . . . . . . . . . 91
11.2. Informational References . . . . . . . . . . . . . . . . 92 11.2. Informational References . . . . . . . . . . . . . . . . 91
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 93 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 93 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92
A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 94 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 93
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 95 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 94
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 95 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 94
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 95 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 94
A.6. Association Setup Response . . . . . . . . . . . . . . . 96 A.6. Association Setup Response . . . . . . . . . . . . . . . 95
A.7. Association Teardown Message . . . . . . . . . . . . . . 97 A.7. Association Teardown Message . . . . . . . . . . . . . . 96
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 98 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 97
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 103 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 102
B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 104 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 103
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 105 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 104
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 109 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 108
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123
Intellectual Property and Copyright Statements . . . . . . . . . 126 Intellectual Property and Copyright Statements . . . . . . . . . 125
1. Terminology and Conventions 1. Terminology and Conventions
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC2119 [RFC2119]. as described in BCP 14, RFC2119 [RFC2119].
1.1. Other Notation 1.1. 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
skipping to change at page 7, line 20 skipping to change at page 7, line 20
plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined
the ForCES requirements, and RFC 3746 has defined the ForCES the ForCES requirements, and RFC 3746 has defined the ForCES
framework. While there may be multiple protocols used within the framework. While there may be multiple protocols used within the
overall ForCES architecture, the term "ForCES protocol" and overall ForCES architecture, the term "ForCES protocol" and
"protocol" as used in this document refers to the protocol used to "protocol" as used in this document refers to the protocol used to
standardize the information exchange between Control Elements (CEs) standardize the information exchange between Control Elements (CEs)
and Forwarding Elements (FEs) only. and Forwarding Elements (FEs) only.
The ForCES FE model [FE-MODEL] presents a formal way to define FE The ForCES FE model [FE-MODEL] presents a formal way to define FE
Logical Function Blocks (LFBs) using XML. LFB configuration Logical Function Blocks (LFBs) using XML. LFB configuration
attributes, capabilities, and associated events are defined when the components, capabilities, and associated events are defined when the
LFB is formally created. The LFBs within the FE are accordingly LFB is formally created. The LFBs within the FE are accordingly
controlled in a standardized way by the ForCES protocol. controlled in a standardized way by the ForCES protocol.
This document defines the ForCES protocol specifications. The ForCES This document defines the ForCES protocol specifications. The ForCES
protocol works in a master-slave mode in which FEs are slaves and CEs protocol works in a master-slave mode in which FEs are slaves and CEs
are masters. The protocol includes commands for transport of Logical are masters. The protocol includes commands for transport of Logical
Function Block(LFB) configuration information, association setup, Function Block(LFB) configuration information, association setup,
status, and event notifications, etc. status, and event notifications, etc.
This specification does not define a transport mechanism for protocol This specification does not define a transport mechanism for protocol
skipping to change at page 16, line 18 skipping to change at page 16, line 18
o complex parameters: send up to 4 association messages with o complex parameters: send up to 4 association messages with
increasing exponential timeout increasing exponential timeout
4.2. ForCES Protocol Phases 4.2. ForCES Protocol Phases
ForCES, in relation to NEs, involves two phases: the Pre-Association ForCES, in relation to NEs, involves two phases: the Pre-Association
phase, where configuration/initialization/bootup of the TML and PL phase, where configuration/initialization/bootup of the TML and PL
layer happens, and the association phase where the ForCES protocol layer happens, and the association phase where the ForCES protocol
operates to manipulate the parameters of the FEs. operates to manipulate the parameters of the FEs.
FE associated CE configures transition to UP CE sends Association Setup
+---->--->---+ +--->---->---->---->------->----+ +---->--->------------>---->---->---->------->----+
| | | Y | Y
^ Y | | ^ |
| | | Y | Y
+---+-------+ +------+--+ +--------+ +---+-------+ +-------------+
|FE Pre- | | FE | | FE | |FE Pre- | | FE |
|Association| | DOWN | CE configures DOWN | UP | |Association| CE sends Association Teardown | Associated |
|Phase | | State +<------<-----<------<-- + State | |Phase |<------- <------<-----<------<-------+ |
| | | | | | | | | |
+-----------+ +---------+ +--------+ +-----------+ +-------------+
^ Y ^ Y
| | | |
+-<---<------<-----<------<----<---------<------+ +-<---<------<-----<------<----<---------<------+
FE loses association FE loses association
Figure 4: The FE State Machine Figure 4: The FE State Machine
In the mandated case, once associated, the FE can only be in one of In the mandated case, once associated, the FE may forward packets
two states, as indicated above. When the FE is in the DOWN state, it depending on the configuration of its specific LFBs. An FE which is
is not forwarding packets. When the FE is in the UP state it may be associated to a CE will continue sending packets until it receives an
forwarding packets, depending on the configuration of its specific Association teardown message or until it loses association. An
LFBs. The FE MAY also be in other states when it is capable of unassociated FE MAY continue sending packets when it is capable high
graceful restart and high availability. The extra transitions are availability. The extra details are explained in Section 8 and not
explained in Section 8 and not discussed here so as to allow us to discussed here to allow for a clear explanation of the basics.
explain the basics with more clarity.
The CE configures FE state transitions by means of the FE Object LFB, The CE configures FE state transitions by means of the FE Object LFB,
which is defined in [FE-MODEL] and also explained in Section 7.3.2. which is defined in [FE-MODEL] and also explained in Section 7.3.2.
In the FE Object LFB, FE state is defined as an attribute of the LFB, In the FE Object LFB, FE state is defined as an attribute of the LFB,
and CE configuration of the FE state equals CE configuration of this and CE configuration of the FE state equals CE configuration of this
attribute. Note that even in the FE DOWN state, the FE is attribute. Note that even in the FE DOWN state, the FE is
associated. associated.
The FE stays in the DOWN state until it is explicitly configured by The FE stays in the DOWN state until it is explicitly configured by
the CE to transition to the UP state via an FE Object admin action. the CE to transition to the UP state via an FE Object admin action.
skipping to change at page 17, line 44 skipping to change at page 17, line 44
The following are scenarios reproduced from the Framework Document to The following are scenarios reproduced from the Framework Document to
show a pre-association example. show a pre-association example.
<----Ff ref pt---> <--Fc ref pt-------> <----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) (security exchange) (security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication 1|<------------>| authentication 1|<----------->|authentication
| | | | | | | |
(FE ID, attributes) (CE ID, attributes) (FE ID, components) (CE ID, components)
2|<-------------| request 2|<------------|request 2|<-------------| request 2|<------------|request
| | | | | | | |
3|------------->| response 3|------------>|response 3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID) (corresponding CE ID) (corresponding FE ID)
| | | | | | | |
| | | | | | | |
Figure 5: Examples of a message exchange over the Ff and Fc reference Figure 5: Examples of a message exchange over the Ff and Fc reference
points points
<-----------Fl ref pt--------------> | <-----------Fl ref pt--------------> |
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) | | (security exchange) | |
1|<------------------------------>| | 1|<------------------------------>| |
| | | | | | | |
(a list of CEs and their attributes) | (a list of CEs and their components) |
2|<-------------------------------| | 2|<-------------------------------| |
| | | | | | | |
(a list of FEs and their attributes) | (a list of FEs and their components) |
3|------------------------------->| | 3|------------------------------->| |
| | | | | | | |
| | | | | | | |
Figure 6: An example of a message exchange over the Fl reference Figure 6: An example of a message exchange over the Fl reference
point point
Before the transition to the association phase, the FEM will have Before the transition to the association phase, the FEM will have
established contact with a CEM component. Initialization of the established contact with a CEM component. Initialization of the
ForCES interface will have completed, and authentication as well as ForCES interface will have completed, and authentication as well as
skipping to change at page 19, line 12 skipping to change at page 19, line 12
o Established Stage o Established Stage
o Association Lost Stage o Association Lost Stage
4.2.2.1. Association Setup Stage 4.2.2.1. Association Setup Stage
The FE attempts to join the NE. The FE may be rejected or accepted. The FE attempts to join the NE. The FE may be rejected or accepted.
Once granted access into the NE, capabilities exchange happens with Once granted access into the NE, capabilities exchange happens with
the CE querying the FE. Once the CE has the FE capability the CE querying the FE. Once the CE has the FE capability
information, the CE can offer an initial configuration (possibly to information, the CE can offer an initial configuration (possibly to
restore state) and can query certain attributes within either an LFB restore state) and can query certain components within either an LFB
or the FE itself. or the FE itself.
More details are provided in Section 4.4. More details are provided in Section 4.4.
On successful completion of this stage, the FE joins the NE and is On successful completion of this stage, the FE joins the NE and is
moved to the Established Stage. moved to the Established Stage.
4.2.2.2. Established Stage 4.2.2.2. Established Stage
In this stage, the FE is continuously updated or queried. The FE may In this stage, the FE is continuously updated or queried. The FE may
skipping to change at page 64, line 40 skipping to change at page 64, line 40
The FE Object LFB is a logical entity in each FE and contains The FE Object LFB is a logical entity in each FE and contains
attributes relative to the FE itself, and not to the operation of the attributes relative to the FE itself, and not to the operation of the
ForCES protocol. ForCES protocol.
The formal definition of the FE Object LFB can be found in The formal definition of the FE Object LFB can be found in
[FE-MODEL]. The model captures the high level properties of the FE [FE-MODEL]. The model captures the high level properties of the FE
that the CE needs to know to begin working with the FE. The class ID that the CE needs to know to begin working with the FE. The class ID
for this LFB Class is also assigned in [FE-MODEL]. The singular for this LFB Class is also assigned in [FE-MODEL]. The singular
instance of this class will always exist, and will always have instance of this class will always exist, and will always have
instance ID 0x1 within its class. It is common, although not instance ID 0x1 within its class. It is common, although not
mandatory, for a CE to fetch much of the attribute and capability mandatory, for a CE to fetch much of the component and capability
information from this LFB instance when the CE begins controlling the information from this LFB instance when the CE begins controlling the
operation of the FE. operation of the FE.
7.4. Semantics of Message Direction 7.4. Semantics of Message Direction
Recall: The PL provides a master(CE)-Slave(FE) relationship. The Recall: The PL provides a master(CE)-Slave(FE) relationship. The
LFBs reside at the FE and are controlled by CE. LFBs reside at the FE and are controlled by CE.
When messages go from the CE, the LFB Selector (Class and instance) When messages go from the CE, the LFB Selector (Class and instance)
refers to the destination LFB selection which resides in the FE. refers to the destination LFB selection which resides in the FE.
skipping to change at page 65, line 37 skipping to change at page 65, line 37
should assign an FE ID for the FE in the setup response message. should assign an FE ID for the FE in the setup response message.
Message body: Message body:
The association setup message body optionally consists of zero, The association setup message body optionally consists of zero,
one or two LFBselect TLVs, as described in Section 7.1.5. The one or two LFBselect TLVs, as described in Section 7.1.5. The
Association Setup message only operates on the FE Object and FE Association Setup message only operates on the FE Object and FE
Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV
only points to these two kinds of LFBs. only points to these two kinds of LFBs.
The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' The OPER-TLV in the LFBselect TLV is defined as a 'REPORT'
operation. More than one attribute may be announced in this operation. More than one component may be announced in this
message using REPORT operation to let the FE declare its message using REPORT operation to let the FE declare its
configuration parameters in an unsolicited manner. These may configuration parameters in an unsolicited manner. These may
contain attributes suggesting values such as the FE HB Interval, contain components suggesting values such as the FE HB Interval,
or the FEID. The OPER-TLV used is defined below. or the FEID. The OPER-TLV used is defined below.
OPER-TLV for Association Setup: OPER-TLV for Association Setup:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
skipping to change at page 67, line 24 skipping to change at page 67, line 24
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
| |
| |
+-- LFBInstance = 0x1 +-- LFBInstance = 0x1
| |
+---OPER-TLV = REPORT +---OPER-TLV = REPORT
| |
+-- Path-data to one or more attributes +-- Path-data to one or more components
Figure 23: PDU Format For Association Setup Message Figure 23: PDU Format For Association Setup Message
7.5.2. Association Setup Response Message 7.5.2. Association Setup Response Message
This message is sent by the CE to the FE in response to the Setup This message is sent by the CE to the FE in response to the Setup
message. It indicates to the FE whether the setup is successful or message. It indicates to the FE whether the setup is successful or
not, i.e., whether an association is established. not, i.e., whether an association is established.
Message transfer direction: Message transfer direction:
skipping to change at page 70, line 12 skipping to change at page 70, line 12
Figure 27: PDU Format for Association Teardown Message Figure 27: PDU Format for Association Teardown Message
7.6. Configuration Messages 7.6. Configuration Messages
The ForCES Configuration messages are used by CE to configure the FEs The ForCES Configuration messages are used by CE to configure the FEs
in a ForCES NE and report the results back to the CE. in a ForCES NE and report the results back to the CE.
7.6.1. Config Message 7.6.1. Config Message
This message is sent by the CE to the FE to configure LFB attributes This message is sent by the CE to the FE to configure LFB components
in the FE. This message is also used by the CE to subscribe/ in the FE. This message is also used by the CE to subscribe/
unsubscribe to LFB events. unsubscribe to LFB events.
As usual, a config message is composed of a common header followed by As usual, a config message is composed of a common header followed by
a message body that consists of one or more TLV data format. a message body that consists of one or more TLV data format.
Detailed description of the message is as below. Detailed description of the message is as below.
Message transfer direction: Message transfer direction:
CE to FE CE to FE
skipping to change at page 70, line 45 skipping to change at page 70, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: OPER-TLV for Config Figure 28: OPER-TLV for Config
Type: Type:
The operation type for config message. two types of operations The operation type for config message. two types of operations
for the config message are defined: for the config message are defined:
Type = "SET" - this operation is to set LFB attributes Type = "SET" - this operation is to set LFB components
Type = "SET-PROP" - this operation is to set LFB attribute Type = "SET-PROP" - this operation is to set LFB component
properties properties
Type = "DEL" - this operation to delete some LFB Type = "DEL" - this operation to delete some LFB
attributes components
Type = "COMMIT" - this operation is sent to the FE to Type = "COMMIT" - this operation is sent to the FE to
commit in a 2pc transaction. A COMMIT TLV is an empty TLV commit in a 2pc transaction. A COMMIT TLV is an empty TLV
i.e it has no "V"alue. In other words, There is a Length i.e it has no "V"alue. In other words, There is a Length
of 4 (which is for the header only). of 4 (which is for the header only).
Type = "TRCOMP" - this operation is sent to the FE to mark Type = "TRCOMP" - this operation is sent to the FE to mark
the success from an NE perspective of a 2pc transaction. the success from an NE perspective of a 2pc transaction.
A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In
other words, There is a Length of 4 (which is for the other words, There is a Length of 4 (which is for the
skipping to change at page 72, line 36 skipping to change at page 72, line 36
. .
. .
Figure 29: PDU Format for Configuration Message Figure 29: PDU Format for Configuration Message
7.6.2. Config Response Message 7.6.2. Config Response Message
This message is sent by the FE to the CE in response to the Config This message is sent by the FE to the CE in response to the Config
message. It indicates whether the Config was successful or not on message. It indicates whether the Config was successful or not on
the FE and also gives a detailed response regarding the configuration the FE and also gives a detailed response regarding the configuration
result of each attribute. result of each component.
Message transfer direction: Message transfer direction:
FE to CE FE to CE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Config The Message Type in the header is set MessageType= 'Config
Response'. The ACK flag in the header is always ignored, and the Response'. The ACK flag in the header is always ignored, and the
Config Response message never expects to get any further response Config Response message never expects to get any further response
from the message receiver (CE). from the message receiver (CE).
skipping to change at page 73, line 20 skipping to change at page 73, line 20
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: OPER-TLV for Config Response Figure 30: OPER-TLV for Config Response
Type: Type:
The operation type for Config Response message. Two types of The operation type for Config Response message. Two types of
operations for the Config Response message are defined: operations for the Config Response message are defined:
Type = "SET-RESPONSE" - this operation is for the response Type = "SET-RESPONSE" - this operation is for the response
of SET operation of LFB attributes of SET operation of LFB components
Type = "SET-PROP-RESPONSE" - this operation is for the Type = "SET-PROP-RESPONSE" - this operation is for the
response of SET-PROP operation of LFB attribute properties response of SET-PROP operation of LFB component properties
Type = "DEL-RESPONSE" - this operation is for the response Type = "DEL-RESPONSE" - this operation is for the response
of the DELETE operation of LFB attributes of the DELETE operation of LFB components
Type = "COMMIT-RESPONSE" - this operation is sent to the Type = "COMMIT-RESPONSE" - this operation is sent to the
CE to confirm a commit success in a 2pc transaction. A CE to confirm a commit success in a 2pc transaction. A
COMMIT-RESPONSE TLV MUST contain a RESULT TLV indicating COMMIT-RESPONSE TLV MUST contain a RESULT TLV indicating
success or failure. success or failure.
PATH-DATA-TLV: PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format that has been defined This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA BNF definition. The in section (Section 7) in the PATH-DATA BNF definition. The
restriction on the use of PATH-DATA-TLV for SET-RESPONSE restriction on the use of PATH-DATA-TLV for SET-RESPONSE
skipping to change at page 74, line 29 skipping to change at page 74, line 29
| // associated with FULL or SPARSEDATA TLV(s) | // associated with FULL or SPARSEDATA TLV(s)
| |
+-- T = operation { DEL-RESPONSE } +-- T = operation { DEL-RESPONSE }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { COMMIT-RESPONSE } +-- T = operation { COMMIT-RESPONSE }
| | | |
| +-- RESULT | +-- RESULT
Figure 31: PDU Format fpr Configuration Response message Figure 31: PDU Format for Configuration Response message
7.7. Query Messages 7.7. Query Messages
The ForCES query messages are used by the CE to query LFBs in the FE The ForCES query messages are used by the CE to query LFBs in the FE
for informations like LFB attributes, capabilities, statistics, etc. for informations like LFB components, capabilities, statistics, etc.
Query Messages include the Query Message and the Query Response Query Messages include the Query Message and the Query Response
Message. Message.
7.7.1. Query Message 7.7.1. Query Message
A Query message is composed of a common header and a message body A Query message is composed of a common header and a message body
that consists of one or more TLV data format. Detailed description that consists of one or more TLV data format. Detailed description
of the message is as below. of the message is as below.
Message transfer direction: Message transfer direction:
skipping to change at page 75, line 22 skipping to change at page 75, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP | | PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: TLV for Query Figure 32: TLV for Query
Type: Type:
The operation type for query. Two operation types are defined: The operation type for query. Two operation types are defined:
Type = "GET" - this operation is to request to get LFB Type = "GET" - this operation is to request to get LFB
attributes. components.
Type = "GET-PROP" - this operation is to request to get Type = "GET-PROP" - this operation is to request to get
LFB attributes. LFB components.
PATH-DATA-TLV for GET/GET-PROP: PATH-DATA-TLV for GET/GET-PROP:
This is generically a PATH-DATA-TLV format that has been defined This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA BNF definition. The in section (Section 7) in the PATH-DATA BNF definition. The
restriction on the use of PATH-DATA-TLV for GET/GET-PROP restriction on the use of PATH-DATA-TLV for GET/GET-PROP
operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV
and RESULT TLV in the data format. and RESULT TLV in the data format.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
format is shown below: format is shown below:
skipping to change at page 77, line 20 skipping to change at page 77, line 20
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: TLV for Query Response Figure 34: TLV for Query Response
Type: Type:
The operation type for query response. One operation type is The operation type for query response. One operation type is
defined: defined:
Type = "GET-RESPONSE" - this operation is to response to Type = "GET-RESPONSE" - this operation is to response to
get operation of LFB attributes. get operation of LFB components.
Type = "GET-PROP-RESPONSE" - this operation is to response Type = "GET-PROP-RESPONSE" - this operation is to response
to GET-PROP operation of LFB attributes. to GET-PROP operation of LFB components.
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
This is generically a PATH-DATA-TLV format that has been defined This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA BNF definition. The in section (Section 7) in the PATH-DATA BNF definition. The
PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA
TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The
RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and
FULLDATA TLVs are defined in Section 7.1.8. FULLDATA TLVs are defined in Section 7.1.8.
To better illustrate the above PDU format, a tree structure for the To better illustrate the above PDU format, a tree structure for the
skipping to change at page 81, line 19 skipping to change at page 81, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: METADARA TLV Figure 39: METADATA TLV
Meta Data ILV: Meta Data ILV:
This is an Identifier-Length-Value format that is used to describe This is an Identifier-Length-Value format that is used to describe
one meta data. The ILV has the format as: one meta data. The ILV has the format as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID | | Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 83, line 7 skipping to change at page 83, line 7
7.10. Heartbeat Message 7.10. Heartbeat Message
The Heartbeat (HB) Message is used for one ForCES element (FE or CE) The Heartbeat (HB) Message is used for one ForCES element (FE or CE)
to asynchronously notify one or more other ForCES elements in the to asynchronously notify one or more other ForCES elements in the
same ForCES NE on its liveness. Section 4.3.3 describes the traffic- same ForCES NE on its liveness. Section 4.3.3 describes the traffic-
sensitive approach used. sensitive approach used.
A Heartbeat Message is sent by a ForCES element periodically. The A Heartbeat Message is sent by a ForCES element periodically. The
parameterization and policy definition for heartbeats for an FE is parameterization and policy definition for heartbeats for an FE is
managed as attributes of the FE Protocol Object LFB, and can be set managed as components of the FE Protocol Object LFB, and can be set
by CE via a Config message. The Heartbeat message is a little by CE via a Config message. The Heartbeat message is a little
different from other protocol messages in that it is only composed of different from other protocol messages in that it is only composed of
a common header, with the message body left empty. A detailed a common header, with the message body left empty. A detailed
description of the message is as below. description of the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE or CE to FE FE to CE or CE to FE
Message Header: Message Header:
The Message Type in the message header is set to MessageType = The Message Type in the message header is set to MessageType =
skipping to change at page 85, line 5 skipping to change at page 85, line 5
High Availability parameterization in an FE is driven by configuring High Availability parameterization in an FE is driven by configuring
the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1).
The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
Heartbeat policy help in detecting connectivity problems between an Heartbeat policy help in detecting connectivity problems between an
FE and CE. The CE Failover policy defines the reaction on a detected FE and CE. The CE Failover policy defines the reaction on a detected
failure. failure.
Figure 43 extends the state machine illustrated in Figure 4 to allow Figure 43 extends the state machine illustrated in Figure 4 to allow
for new states that facilitate connection recovery. for new states that facilitate connection recovery.
+-----------------+ (CE issues Teardown || +-----------------+
Lost association && | Pre-Association | Lost association) && | Pre-Association |
CE failover policy = 0 | (Association | CE failover policy = 0 | (Association |
+------------>-->--| in +<----+ +------------>-->-->| in +<----+
| | progress) | | | | progress) | |
| +--------+--------+ | | CE Issues +--------+--------+ |
| | | | Association | | CFTI
| Y | | Setup V | timer
| | | | ___________________+ | expires
| Associated ^
| | |
| Y |
| | | | | |
| +-------+-------+ | | V ^
| CE issues | DOWN FE | | +-+-----------+ +-------+-----+
| FEO Admin | (ForCES | ^ | | | Not |
| UP | Active) | | | | (CE issues Teardown || | Associated |
| +-------- | | | | | Lost association) && | |
| | | | | | Associated | CE Failover Policy = 1 | (May |
| | +---------------+ ^ | | | Continue |
| Y ^ | | |---------->------->------>| Forwarding)|
| | | |CEFTI expired | | | |
| Y |CE issues Admin | &&
| | | DOWN |!connected
| | | ^
| Y | |
+-+-----------+ | +------+------+
| UP |------------+ |Disconnected |
|(associated) | | |
| |Lost association | |
| | && | |
| |--------->------>----->|(Continue |
| |CE failover policy |Forwarding) |
| | = 1 | |
+-------------+ +-------------+ +-------------+ +-------------+
^ | ^ V
| Resynchronize !CEFTI expired | | |
| complete && | | CE Issues |
| reconnected | | Association |
| +---------------+ | | Setup |
| | Resynch state | | +_________________________________________+
| | (via | |
+-----------| graceful |<--------+
| restart) |
+---------------+
Figure 43: FE State Machine considering HA Figure 43: FE State Machine considering HA
Section 4.2 describes transitions between the UP, DOWN and Pre-
association states. In this section we deal with disconnected
states.
During a communication failure between the FE and CE (which is caused Section 4.2 describes transitions between the Pre-association,
due to CE or link reasons, i.e. not FE related), either the TML on associated and not associated states.
the FE will trigger the FE PL regarding this failure or it will be
When communication fails between the FE and CE (which can be caused
by either the CE or link failure but not FE related), either the TML
on the FE will trigger the FE PL regarding this failure or it will be
detected using the HB messages between FEs and CEs. The detected using the HB messages between FEs and CEs. The
communication failure, regardless of how it is detected, MUST be communication failure, regardless of how it is detected, MUST be
considered as a loss of association between the CE and corresponding considered as a loss of association between the CE and corresponding
FE. FE.
If the FE's FEPO CE Failover Policy is configured to mode 0 (the If the FE's FEPO CE Failover Policy is configured to mode 0 (the
default), it will immediately transition to the pre-association default), it will immediately transition to the pre-association
phase. This means that if it ever reconnects again, it will re- phase. This means that if association is again established, all FE
establish state from scratch. state will need to be re-established.
If the FE's FEPO CE Failover Policy is configured to mode 1, it If the FE's FEPO CE Failover Policy is configured to mode 1, it
implies that the FE is capable of HA as well as graceful restart indicates that the FE is capable of HA restart recovery. In such a
recovery. In such a case, the FE transitions to the disconnected case, the FE transitions to the not associated state and the CEFTI
state and the CEFTI timer is started. The FE continues to forward timer is started. The FE MAY continue to forward packets during this
packets during this state. It also recycles through its configured state. It MAY also recycle through any configured secondary CEs in a
secondary CEs in a round-robin fashion. It first adds its primary CE round-robin fashion. It first adds its primary CE to the tail of
to the tail of backup CEs and sets its primary CE to be the first backup CEs and sets its primary CE to be the first secondary. It
secondary. It then attempts to connect to associate with the new then attempts to associate with the CE designated as the new primary
primary CE. If it fails to re-associate with any CE and the CEFTI CE. If it fails to re-associate with any CE and the CEFTI expires,
expires, the FE transitions to the Pre-association state. the FE then transitions to the Pre-association state.
If the FE, while in the Disconnected state, manages to reconnect to a If the FE, while in the not associated state, manages to reconnect to
new primary CE before CEFTI expires it transitions to the Resynch a new primary CE before CEFTI expires it transitions to the
state. In the Resynch state, the FE tries to recover any state that Associated state. Once re-associated, the FE tries to recover any
may have been lost during the Disonnected state. Graceful restart is state that may have been lost during the not associated state. How
one such mechanism. How the FE achieves these goals is out of scope the FE achieves re-synchronizes it state is out of scope for this
for this document. document.
Figure 44 below illustrates the Forces message sequences that the FE Figure 44 below illustrates the Forces message sequences that the FE
uses to recover the connection. uses to recover the connection.
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| All msgs | | | All msgs | |
skipping to change at page 87, line 32 skipping to change at page 87, line 5
| All Msgs | | All Msgs |
5 |<------------------------------------------>| 5 |<------------------------------------------>|
Figure 44: CE Failover for Report Primary Mode Figure 44: CE Failover for Report Primary Mode
A CE-to-CE synchronization protocol would be needed to support fast A CE-to-CE synchronization protocol would be needed to support fast
failover as well as to address some of the corner cases, however this failover as well as to address some of the corner cases, however this
will not be defined by the ForCES protocol as it is out of scope for will not be defined by the ForCES protocol as it is out of scope for
this specification. this specification.
An explicit message (a Config message setting Primary CE attribute in An explicit message (a Config message setting Primary CE component in
ForCES Protocol object) from the primary CE, can also be used to ForCES Protocol object) from the primary CE, can also be used to
change the Primary CE for an FE during normal protocol operation. change the Primary CE for an FE during normal protocol operation.
Also note that the FEs in a ForCES NE could also use a multicast CE Also note that the FEs in a ForCES NE could also use a multicast CE
ID, i.e., they could be associated with a group of CEs (this assumes ID, i.e., they could be associated with a group of CEs (this assumes
the use of a CE-CE synchronization protocol, which is out of scope the use of a CE-CE synchronization protocol, which is out of scope
for this specification). In this case, the loss of association would for this specification). In this case, the loss of association would
mean that communication with the entire multicast group of CEs has mean that communication with the entire multicast group of CEs has
been lost. The mechanisms described above will apply for this case been lost. The mechanisms described above will apply for this case
as well during the loss of association. If, however, the secondary as well during the loss of association. If, however, the secondary
skipping to change at page 91, line 5 skipping to change at page 90, line 5
9.2.2. Message authentication service 9.2.2. Message authentication service
This is a TML specific operation and is transparent to the ForCES PL. This is a TML specific operation and is transparent to the ForCES PL.
For details, refer to Section 5. For details, refer to Section 5.
9.2.3. Confidentiality service 9.2.3. Confidentiality service
This is a TML specific operation and is transparent to the ForCES PL. This is a TML specific operation and is transparent to the ForCES PL.
For details, refer to Section 5. For details, refer to Section 5.
10. Acknowledgments 10. Acknowledgements
The authors of this draft would like to acknowledge and thank the The authors of this draft would like to acknowledge and thank the
ForCES Working Group and especially the following: Furquan Ansari, ForCES Working Group and especially the following: Furquan Ansari,
Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M.
Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M.
Halpern (who should probably be listed among the authors), Zsolt Halpern (who should probably be listed among the authors), Zsolt
Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering,
T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their
contributions. We would also like to thank David Putzolu, and contributions. We would also like to thank David Putzolu, and
Patrick Droz for their comments and suggestions on the protocol and Patrick Droz for their comments and suggestions on the protocol and
skipping to change at page 98, line 10 skipping to change at page 97, line 10
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 attributes 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="http://ietf.org/forces/1.0/lfbmodel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation= xsi:schemaLocation=
"http://ietf.org/forces/1.0/lfbmodel "http://ietf.org/forces/1.0/lfbmodel
provides="FEPO"> provides="FEPO">
<!-- XXX --> <!-- XXX -->
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
skipping to change at page 100, line 40 skipping to change at page 99, line 40
<synopsis> <synopsis>
The FE supports HA The FE supports HA
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="1"> <LFBClassDef LFBClassID="2">
<name>FEPO</name> <name>FEPO</name>
<synopsis> <synopsis>
The FE Protocol Object The FE Protocol Object
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<attributes> <components>
<attribute componentID="1" access="read-only"> <component componentID="1" access="read-only">
<name>CurrentRunningVersion</name> <name>CurrentRunningVersion</name>
<synopsis>Currently running ForCES version</synopsis> <synopsis>Currently running ForCES version</synopsis>
<typeRef>u8</typeRef> <typeRef>u8</typeRef>
</attribute> </component>
<attribute componentID="2" access="read-only"> <component componentID="2" access="read-only">
<name>FEID</name> <name>FEID</name>
<synopsis>Unicast FEID</synopsis> <synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
<attribute componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>MulticastFEIDs</name> <name>MulticastFEIDs</name>
<synopsis> <synopsis>
the table of all multicast IDs the table of all multicast IDs
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</attribute> </component>
<attribute componentID="4" access="read-write"> <component componentID="4" access="read-write">
<name>CEHBPolicy</name> <name>CEHBPolicy</name>
<synopsis> <synopsis>
The CE Heartbeat Policy The CE Heartbeat Policy
</synopsis> </synopsis>
<typeRef>CEHBPolicyValues</typeRef> <typeRef>CEHBPolicyValues</typeRef>
</attribute> </component>
<attribute componentID="5" access="read-write"> <component componentID="5" access="read-write">
<name>CEHDI</name> <name>CEHDI</name>
<synopsis> <synopsis>
The CE Heartbeat Dead Interval in millisecs The CE Heartbeat Dead Interval in millisecs
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
<attribute componentID="6" access="read-write"> <component componentID="6" access="read-write">
<name>FEHBPolicy</name> <name>FEHBPolicy</name>
<synopsis> <synopsis>
The FE Heartbeat Policy The FE Heartbeat Policy
</synopsis> </synopsis>
<typeRef>FEHBPolicyValues</typeRef> <typeRef>FEHBPolicyValues</typeRef>
</attribute> </component>
<attribute componentID="7" access="read-write"> <component componentID="7" access="read-write">
<name>FEHI</name> <name>FEHI</name>
<synopsis> <synopsis>
The FE Heartbeat Interval in millisecs The FE Heartbeat Interval in millisecs
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
<attribute componentID="8" access="read-write"> <component componentID="8" access="read-write">
<name>CEID</name> <name>CEID</name>
<synopsis> <synopsis>
The Primary CE this FE is associated with The Primary CE this FE is associated with
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
<attribute componentID="9" access="read-write"> <component componentID="9" access="read-write">
<name>BackupCEs</name> <name>BackupCEs</name>
<synopsis> <synopsis>
The table of all backup CEs other than the primary The table of all backup CEs other than the primary
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array> </array>
</attribute> </component>
<attribute componentID="10" access="read-write"> <component componentID="10" access="read-write">
<name>CEFailoverPolicy</name> <name>CEFailoverPolicy</name>
<synopsis> <synopsis>
The CE Failover Policy The CE Failover Policy
</synopsis> </synopsis>
<typeRef>CEFailoverPolicyValues</typeRef> <typeRef>CEFailoverPolicyValues</typeRef>
</attribute> </component>
<attribute componentID="11" access="read-write"> <component componentID="11" access="read-write">
<name>CEFTI</name> <name>CEFTI</name>
<synopsis> <synopsis>
The CE Failover Timeout Interval in millisecs The CE Failover Timeout Interval in millisecs
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
<attribute componentID="12" access="read-write"> <component componentID="12" access="read-write">
<name>FERestartPolicy</name> <name>FERestartPolicy</name>
<synopsis> <synopsis>
The FE Restart Policy The FE Restart Policy
</synopsis> </synopsis>
<typeRef>FERestartPolicyValues</typeRef> <typeRef>FERestartPolicyValues</typeRef>
</attribute> </component>
<attribute componentID="13" access="read-write"> <component componentID="13" access="read-write">
<name>LastCEID</name> <name>LastCEID</name>
<synopsis> <synopsis>
The Primary CE this FE was last associated with The Primary CE this FE was last associated with
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </component>
</attributes> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>SupportableVersions</name> <name>SupportableVersions</name>
<synopsis> <synopsis>
the table of ForCES versions that FE supports the table of ForCES versions that FE supports
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>u8</typeRef> <typeRef>u8</typeRef>
</array> </array>
skipping to change at page 104, line 5 skipping to change at page 103, line 5
B.1. Capabilities B.1. Capabilities
Supportable Versions enumerates all ForCES versions that an FE Supportable Versions enumerates all ForCES versions that an FE
supports. supports.
FEHACapab enumerates the HA capabilities of the FE. If the FE is not FEHACapab enumerates the HA capabilities of the FE. If the FE is not
capable of Graceful restarts or HA, then it will not be able to capable of Graceful restarts or HA, then it will not be able to
participate in HA as described in Section 8.1 participate in HA as described in Section 8.1
B.2. Attributes B.2. Components
All Attributes are explained in Section 7.3.1. All Components are explained in Section 7.3.1.
Appendix C. Data Encoding Examples Appendix C. Data Encoding Examples
In this section a few examples of data encoding are discussed. these In this section a few examples of data encoding are discussed. these
example, however, do not show any padding. example, however, do not show any padding.
========== ==========
Example 1: Example 1:
========== ==========
skipping to change at page 109, line 7 skipping to change at page 108, line 7
ComponentIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ComponentID = 15 (index 15 from z[]), lengthof(all below) ComponentID = 15 (index 15 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
Note the holes in the components of z (10 followed by 15). Also note Note the holes in the components of z (10 followed by 15). Also note
the gap in index 15 with only components a and c appearing but not b. the gap in index 15 with only components a and c appearing but not b.
Appendix D. Use Cases Appendix D. Use Cases
Assume LFB with following attributes for the following use cases. Assume LFB with following components for the following use cases.
foo1, type u32, ID = 1 foo1, type u32, ID = 1
foo2, type u32, ID = 2 foo2, type u32, ID = 2
table1: type array, ID = 3 table1: type array, ID = 3
components are: components are:
t1, type u32, ID = 1 t1, type u32, ID = 1
t2, type u32, ID = 2 // index into table 2 t2, type u32, ID = 2 // index into table 2
KEY: nhkey, ID = 1, V = t2 KEY: nhkey, ID = 1, V = t2
skipping to change at page 110, line 4 skipping to change at page 109, line 4
components are: components are:
p1, type u32, ID = 1 p1, type u32, ID = 1
p2, type array, ID = 2, array components of type-X p2, type array, ID = 2, array components of type-X
Type-X: Type-X:
x1, ID 1, type u32 x1, ID 1, type u32
x2, ID2 , type u32 x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1} KEY: tkey, ID = 1, V = { x1}
All examples will use valueof(x) to indicate the value of the All examples will use valueof(x) to indicate the value of the
referenced attribute x. In the case where F_SEL** are missing (bits referenced component x. In the case where F_SEL** are missing (bits
equal to 00) then the flags will not show any selection. equal to 00) then the flags will not show any selection.
All the examples only show use of FULLDATA for data encoding; All the examples only show use of FULLDATA for data encoding;
although SPARSEDATA would make more sense in certain occasions, the although SPARSEDATA would make more sense in certain occasions, the
emphasis is on showing the message layout. Refer to Appendix C for emphasis is on showing the message layout. Refer to Appendix C for
examples that show usage of both FULLDATA and SPARSEDATA. examples that show usage of both FULLDATA and SPARSEDATA.
1. To get foo1 1. To get foo1
OPER = GET-TLV OPER = GET-TLV
skipping to change at page 123, line 32 skipping to change at page 122, line 32
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1 flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV RESULT-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1 flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV RESULT-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV RESULT-TLV
18. Get a whole LFB (all its attributes, etc.). 18. Get a whole LFB (all its components, etc.).
For example: at startup a CE might well want the entire FE For example: at startup a CE might well want the entire FE
OBJECT LFB. So, in a request targeted at class 1, instance OBJECT LFB. So, in a request targeted at class 1, instance
1, one might find: 1, one might find:
operation = GET-TLV operation = GET-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 0 flags = 0 IDCount = 0
result: result:
 End of changes. 67 change blocks. 
177 lines changed or deleted 161 lines changed or added

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