draft-ietf-forces-protocol-11.txt   draft-ietf-forces-protocol-12.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: January 9, 2008 IBM Expires: May 21, 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
July 8, 2007 November 18, 2007
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-11.txt draft-ietf-forces-protocol-12.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 January 9, 2008. This Internet-Draft will expire on May 21, 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 40, line 47 skipping to change at page 40, line 47
6.2.2. Scope of the T in TLV 6.2.2. Scope of the T in TLV
The "Type" values in the TLV are global in scope. This means that The "Type" values in the TLV are global in scope. This means that
wherever TLVs occur in the PDU, a specific Type value refers to the wherever TLVs occur in the PDU, a specific Type value refers to the
same Type of TLV. This is a design choice that was made to ease same Type of TLV. This is a design choice that was made to ease
debugging of the protocol. debugging of the protocol.
6.3. ILV 6.3. ILV
A slight variation of the TLV known as the ILV. This sets the type A slight variation of the TLV known as the ILV. This sets the type
("T") to be a 32-bit local index that refers to a ForCES element ID. ("T") to be a 32-bit local index that refers to a ForCES component
(refer to Section 6.4.1). The Length part of the ILV is fixed at 32 ID. (refer to Section 6.4.1). The Length part of the ILV is fixed at
bits. 32 bits.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
skipping to change at page 41, line 44 skipping to change at page 41, line 44
6.4.1. Paths 6.4.1. Paths
The model draft [FE-MODEL] defines an XML-based language that allows The model draft [FE-MODEL] defines an XML-based language that allows
for a formal definition of LFBs. This is similar to the relationship for a formal definition of LFBs. This is similar to the relationship
between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB
and ASN.1 being analogous to the XML model language). Any entity and ASN.1 being analogous to the XML model language). Any entity
that the CE configures on an FE MUST be formally defined in an LFB. that the CE configures on an FE MUST be formally defined in an LFB.
These entities could be scalars (e.g., a 32-bit IPv4 address) or These entities could be scalars (e.g., a 32-bit IPv4 address) or
vectors (such as a nexthop table). Each entity within the LFB is vectors (such as a nexthop table). Each entity within the LFB is
given a numeric 32-bit identifier known as an "element id". This given a numeric 32-bit identifier known as an "component id". This
scheme allows the attribute to be "addressed" in a protocol scheme allows the attribute to be "addressed" in a protocol
construct. construct.
These addressable entities could be hierarchical (e.g., a table These addressable entities could be hierarchical (e.g., a table
column or a cell within a table row). In order to address column or a cell within a table row). In order to address
hierarchical data, the concept of a path is introduced by the model hierarchical data, the concept of a path is introduced by the model
[FE-MODEL]. A path is a series of 32-bit element IDs which are [FE-MODEL]. A path is a series of 32-bit component IDs which are
typically presented in a dot-notation (e.g., 1.2.3.4). Section typically presented in a dot-notation (e.g., 1.2.3.4). Section
(Section 7) formally defines how paths are used to reference data (Section 7) formally defines how paths are used to reference data
that is being encapsulated within a protocol message. that is being encapsulated within a protocol message.
6.4.2. Keys 6.4.2. Keys
The model draft [FE-MODEL] defines two ways to address table rows. The model draft [FE-MODEL] defines two ways to address table rows.
The standard/common mechanism is to allow table rows to be referenced The standard/common mechanism is to allow table rows to be referenced
by a 32-bit index. The secondary mechanism is via Keys which allow by a 32-bit index. The secondary mechanism is via Keys which allow
for content addressing. An example key is a multi-field content key for content addressing. An example key is a multi-field content key
skipping to change at page 42, line 34 skipping to change at page 42, line 34
In FULLDATA TLV, the data is encoded in such a way that a receiver of In FULLDATA TLV, the data is encoded in such a way that a receiver of
such data, by virtue of being armed with knowledge of the path and such data, by virtue of being armed with knowledge of the path and
the LFB definition, can infer or correlate the TLV "Value" contents. the LFB definition, can infer or correlate the TLV "Value" contents.
This is essentially an optimization that helps reduce the amount of This is essentially an optimization that helps reduce the amount of
description required for the transported data in the protocol description required for the transported data in the protocol
grammar. Refer to Appendix C for an example of FULLDATA TLVs. grammar. Refer to Appendix C for an example of FULLDATA TLVs.
A number of operations in ForCES will need to reference optional data A number of operations in ForCES will need to reference optional data
within larger structures. The SPARSEDATA TLV encoding is provided to within larger structures. The SPARSEDATA TLV encoding is provided to
make it easier to encapsulate optionally appearing data elements. make it easier to encapsulate optionally appearing data components.
Refer to Appendix C for an example of SPARSEDATA TLV. Refer to Appendix C for an example of SPARSEDATA TLV.
RESULT TLVs carry responses back from the FE based on a config issued RESULT TLVs carry responses back from the FE based on a config issued
by the CE. Refer to Appendix C for examples of RESULT TLVs and by the CE. Refer to Appendix C for examples of RESULT TLVs and
Section 7.1.7 for layout. Section 7.1.7 for layout.
6.4.4. Addressing LFB entities 6.4.4. Addressing LFB entities
Section 6.4.1 and Section 6.4.2 discuss how to target an entity Section 6.4.1 and Section 6.4.2 discuss how to target an entity
within an LFB. However, the addressing mechanism used requires that within an LFB. However, the addressing mechanism used requires that
skipping to change at page 45, line 23 skipping to change at page 45, line 23
and selectors of interest. The following BNF describes the basic and selectors of interest. The following BNF describes the basic
structure of an OPER-TLV and Table 2 gives the details for each type structure of an OPER-TLV and Table 2 gives the details for each type
OPER-TLV := 1*PATH-DATA-TLV OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA] PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR] PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV 1*PATH-DATA-TLV
KEYINFO-TLV := KeyID FULLDATA-TLV KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data element which may nest FULLDATA-TLV := encoded data component which may nest
further FULLDATA-TLVs further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally SPARSEDATA-TLV := encoded data that may have optionally
appearing elements appearing components
RESULT-TLV := Holds result code and optional FULLDATA-TLV RESULT-TLV := Holds result code and optional FULLDATA-TLV
Figure 17: BNF of OPER-TLV Figure 17: BNF of OPER-TLV
o PATH-DATA-TLV identifies the exact element targeted and may have o PATH-DATA-TLV identifies the exact component targeted and may have
zero or more paths associated with it. The last PATH-DATA-TLV in zero or more paths associated with it. The last PATH-DATA-TLV in
the case of nesting of paths via the DATA construct in the case of the case of nesting of paths via the DATA construct in the case of
SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is
terminated by encoded data or response in the form of either terminated by encoded data or response in the form of either
FULLDATA-TLV or SPARSEDATA-TLV or RESULT TLV. FULLDATA-TLV or SPARSEDATA-TLV or RESULT TLV.
o PATH provides the path to the data being referenced. o PATH provides the path to the data being referenced.
* flags (16 bits) are used to further refine the operation to be * flags (16 bits) are used to further refine the operation to be
applied on the Path. More on these later. applied on the Path. More on these later.
skipping to change at page 52, line 20 skipping to change at page 52, line 20
A GET-RESPONSE in response to a successful GET will have FULLDATA A GET-RESPONSE in response to a successful GET will have FULLDATA
TLVs added to the leaf paths to carry the requested data. For GET TLVs added to the leaf paths to carry the requested data. For GET
operations that fail, instead of the FULLDATA TLV there will be a operations that fail, instead of the FULLDATA TLV there will be a
RESULT TLV. RESULT TLV.
For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA or SPARSEDATA TLV For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA or SPARSEDATA TLV
in the original request will be replaced with a RESULT TLV in the in the original request will be replaced with a RESULT TLV in the
response. If the request set the FailureACK flag, then only those response. If the request set the FailureACK flag, then only those
items which failed will appear in the response. If the request was items which failed will appear in the response. If the request was
for AlwaysACK, then all elements of the request will appear in the for AlwaysACK, then all components of the request will appear in the
response with RESULT TLVs. response with RESULT TLVs.
Note that if a SET/SET-PROP request with a structure in a FULLDATA is Note that if a SET/SET-PROP request with a structure in a FULLDATA is
issued, and some field in the structure is invalid, the FE will not issued, and some field in the structure is invalid, the FE will not
attempt to indicate which field was invalid, but rather will indicate attempt to indicate which field was invalid, but rather will indicate
that the operation failed. Note further that if there are multiple that the operation failed. Note further that if there are multiple
errors in a single leaf PATH-DATA/FULLDATA, the FE can select which errors in a single leaf PATH-DATA/FULLDATA, the FE can select which
error it chooses to return. So if a FULLDATA for a SET/SET-PROP of a error it chooses to return. So if a FULLDATA for a SET/SET-PROP of a
structure attempts to write one field which is read only, and structure attempts to write one field which is read only, and
attempts to set another field to an invalid value, the FE can return attempts to set another field to an invalid value, the FE can return
indication of either error. indication of either error.
A SET/SET-PROP operation on a variable length element with a length A SET/SET-PROP operation on a variable length component with a length
of 0 for the item is not the same as deleting it. If the CE wishes of 0 for the item is not the same as deleting it. If the CE wishes
to delete then the DEL operation should be used whether the path to delete then the DEL operation should be used whether the path
refers to an array element or an optional structure element. refers to an array component or an optional structure component.
7.1.7. Result TLV 7.1.7. Result TLV
The RESULT TLV is an instance of TLV defined in Section 6.2. The The RESULT TLV is an instance of TLV defined in Section 6.2. The
definition is as below: definition is as below:
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 = RESULT | Length | | Type = RESULT | Length |
skipping to change at page 53, line 40 skipping to change at page 53, line 40
| | | currently in use. | | | | currently in use. |
| | | | | | | |
| E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known |
| | | but the specified | | | | but the specified |
| | | instance of that class | | | | instance of that class |
| | | does not exist. | | | | does not exist. |
| | | | | | | |
| E_INVALID_PATH | 0x08 | The specified path is | | E_INVALID_PATH | 0x08 | The specified path is |
| | | impossible. | | | | impossible. |
| | | | | | | |
| E_ELEMENT_DOES_NOT_EXIST | 0x09 | The specified path is | | E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is |
| | | possible but the | | | | possible but the |
| | | element does not exist | | | | component does not |
| | | (e.g., attempt to | | | | exist (e.g., attempt to |
| | | modify a table row that | | | | modify a table row that |
| | | has not been created). | | | | has not been created). |
| | | | | | | |
| E_EXISTS | 0x0A | The specified object | | E_EXISTS | 0x0A | The specified object |
| | | exists but it cannot | | | | exists but it cannot |
| | | exist for the operation | | | | exist for the operation |
| | | to succeed (e.g., | | | | to succeed (e.g., |
| | | attempt to add an | | | | attempt to add an |
| | | existing LFB instance | | | | existing LFB instance |
| | | or array subscript). | | | | or array subscript). |
skipping to change at page 55, line 38 skipping to change at page 55, line 38
| | | decide what went wrong) | | | | decide what went wrong) |
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
Table 4 Table 4
7.1.8. DATA TLV 7.1.8. DATA TLV
A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the
data value/contents. Likewise, a SPARSEDATA TLV has "T" = data value/contents. Likewise, a SPARSEDATA TLV has "T" =
SPARSEDATA, a 16-bit Length, followed by the data value/contents. In SPARSEDATA, a 16-bit Length, followed by the data value/contents. In
the case of the SPARSEDATA, each element in the Value part of the TLV the case of the SPARSEDATA, each component in the Value part of the
will be further encapsulated in an ILV. TLV will be further encapsulated in an ILV.
Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs. Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs.
Appendix C is very useful in illustrating these rules: Appendix C is very useful in illustrating these rules:
1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used
for the alignment MUST be zero on transmission and MUST be for the alignment MUST be zero on transmission and MUST be
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
element 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
elements 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 element in the same order in which the data was defined each component in the same order in which the data was defined
in the LFB specification. This ensures the decoder is able to in the LFB specification. This ensures the decoder is able to
retrieve the data. To use the example 1 again in Appendix C, retrieve the data. To use the example 1 again in Appendix C,
this implies the encoder/decoder is assumed to have knowledge this implies the encoder/decoder is assumed to have knowledge
of how structure S is laid out in the definition. 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 element. 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 inside
FULLDATA TLVs. FULLDATA TLVs.
skipping to change at page 56, line 37 skipping to change at page 56, line 37
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.
6. A FULLDATA can also contain a FULLDATA for variable sized 6. A FULLDATA can also contain a FULLDATA for variable sized
elements. The decoding disambiguation is assumed from rule #3 components. The decoding disambiguation is assumed from rule #3
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.
skipping to change at page 96, line 14 skipping to change at page 96, line 14
0x00 E_SUCCESS 0x00 E_SUCCESS
0x01 E_INVALID_HEADER 0x01 E_INVALID_HEADER
0x02 E_LENGTH_MISMATCH 0x02 E_LENGTH_MISMATCH
0x03 E_VERSION_MISMATCH 0x03 E_VERSION_MISMATCH
0x04 E_INVALID_DESTINATION_PID 0x04 E_INVALID_DESTINATION_PID
0x05 E_LFB_UNKNOWN 0x05 E_LFB_UNKNOWN
0x06 E_LFB_NOT_FOUND 0x06 E_LFB_NOT_FOUND
0x07 E_LFB_INSTANCE_ID_NOT_FOUND 0x07 E_LFB_INSTANCE_ID_NOT_FOUND
0x08 E_INVALID_PATH 0x08 E_INVALID_PATH
0x09 E_ELEMENT_DOES_NOT_EXIST 0x09 E_COMPONENT_DOES_NOT_EXIST
0x0A E_EXISTS 0x0A E_EXISTS
0x0B E_NOT_FOUND 0x0B E_NOT_FOUND
0x0C E_READ_ONLY 0x0C E_READ_ONLY
0x0D E_INVALID_ARRAY_CREATION 0x0D E_INVALID_ARRAY_CREATION
0x0E E_VALUE_OUT_OF_RANGE 0x0E E_VALUE_OUT_OF_RANGE
0x0F E_CONTENTS_TOO_LONG 0x0F E_CONTENTS_TOO_LONG
0x10 E_INVALID_PARAMETERS 0x10 E_INVALID_PARAMETERS
0x11 E_INVALID_MESSAGE_TYPE 0x11 E_INVALID_MESSAGE_TYPE
0x12 E_E_INVALID_FLAGS 0x12 E_E_INVALID_FLAGS
0x13 E_INVALID_TLV 0x13 E_INVALID_TLV
skipping to change at page 100, line 48 skipping to change at page 100, line 48
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="1"> <LFBClassDef LFBClassID="1">
<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> <attributes>
<attribute elementID="1" access="read-only"> <attribute 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> </attribute>
<attribute elementID="2" access="read-only"> <attribute 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> </attribute>
<attribute elementID="3" access="read-write"> <attribute 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> </attribute>
<attribute elementID="4" access="read-write"> <attribute 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> </attribute>
<attribute elementID="5" access="read-write"> <attribute 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> </attribute>
<attribute elementID="6" access="read-write"> <attribute 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> </attribute>
<attribute elementID="7" access="read-write"> <attribute 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> </attribute>
<attribute elementID="8" access="read-write"> <attribute 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> </attribute>
<attribute elementID="9" access="read-write"> <attribute 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> </attribute>
<attribute elementID="10" access="read-write"> <attribute 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> </attribute>
<attribute elementID="11" access="read-write"> <attribute 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> </attribute>
<attribute elementID="12" access="read-write"> <attribute 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> </attribute>
<attribute elementID="13" access="read-write"> <attribute 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> </attribute>
</attributes> </attributes>
<capabilities> <capabilities>
<capability elementID="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>
</capability> </capability>
<capability elementID="31"> <capability componentID="31">
<name>HACapabilities</name> <name>HACapabilities</name>
<synopsis> <synopsis>
the table of HA capabilities the FE supports the table of HA capabilities the FE supports
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>FEHACapab</typeRef> <typeRef>FEHACapab</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
skipping to change at page 105, line 27 skipping to change at page 105, line 27
uint16 a uint16 a
uint16 b uint16 b
uint16 c uint16 c
} }
(a) Describing all fields using SPARSEDATA (a) Describing all fields using SPARSEDATA
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields (b) Describing a subset of fields
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
Note: Even though there are non-optional elements in structure S, Note: Even though there are non-optional components in structure S,
since one can uniquely identify elements, one can selectively send since one can uniquely identify components, one can selectively send
element of structure S (eg in the case of an update from CE to FE). component of structure S (eg in the case of an update from CE to FE).
(c) Describing all fields using a FULLDATA TLV (c) Describing all fields using a FULLDATA TLV
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
FULLDATA TLV FULLDATA TLV
valueof(a) valueof(a)
valueof(b) valueof(b)
valueof(c) valueof(c)
========== ==========
skipping to change at page 106, line 24 skipping to change at page 106, line 24
uint16 c (optional) uint16 c (optional)
} }
This example is identical to Example 1, as illustrated below. This example is identical to Example 1, as illustrated below.
(a) Describing all fields using SPARSEDATA (a) Describing all fields using SPARSEDATA
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA (b) Describing a subset of fields using SPARSEDATA
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
(c) Describing all fields using a FULLDATA TLV (c) Describing all fields using a FULLDATA TLV
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
FULLDATA TLV FULLDATA TLV
valueof(a) valueof(a)
valueof(b) valueof(b)
valueof(c) valueof(c)
skipping to change at page 107, line 18 skipping to change at page 107, line 18
struct U { struct U {
uint16 a uint16 a
string b (optional) string b (optional)
uint16 c (optional) uint16 c (optional)
} }
(a) Describing all fields using SPARSEDATA (a) Describing all fields using SPARSEDATA
Path to an instance of U ... Path to an instance of U ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA (b) Describing a subset of fields using SPARSEDATA
Path to an instance of U ... Path to an instance of U ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
(c) Describing all fields using FULLDATA TLV (c) Describing all fields using FULLDATA TLV
Path to an instance of U ... Path to an instance of U ...
FULLDATA TLV FULLDATA TLV
valueof(a) valueof(a)
FULLDATA TLV FULLDATA TLV
valueof(b) valueof(b)
valueof(c) valueof(c)
Note: The variable-length field requires the addition of a FULLDATA Note: The variable-length field requires the addition of a FULLDATA
TLV within the outer FULLDATA TLV as in the case of element b above. TLV within the outer FULLDATA TLV as in the case of component b
above.
========== ==========
Example 4: Example 4:
========== ==========
Structure containing an array of another structure type. Structure containing an array of another structure type.
struct V { struct V {
uint32 x uint32 x
uint32 y uint32 y
skipping to change at page 108, line 4 skipping to change at page 108, line 5
Example 4: Example 4:
========== ==========
Structure containing an array of another structure type. Structure containing an array of another structure type.
struct V { struct V {
uint32 x uint32 x
uint32 y uint32 y
struct U z[] struct U z[]
} }
(a) Encoding using SPARSEDATA, with two instances of z[], also (a) Encoding using SPARSEDATA, with two instances of z[], also
described with SPARSEDATA, assuming only the 10th and 15th subscript described with SPARSEDATA, assuming only the 10th and 15th subscript
of z[] are encoded. of z[] are encoded.
path to instance of V ... path to instance of V ...
SPARSEDATA TLV SPARSEDATA TLV
ElementIDof(x), lengthof(x), valueof(x) ComponentIDof(x), lengthof(x), valueof(x)
ElementIDof(y), lengthof(y), valueof(y) ComponentIDof(y), lengthof(y), valueof(y)
ElementIDof(z), lengthof(all below) ComponentIDof(z), lengthof(all below)
ElementID = 10 (i.e index 10 from z[]), lengthof(all below) ComponentID = 10 (i.e index 10 from z[]), lengthof(all below)
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ElementID = 15 (index 15 from z[]), lengthof(all below) ComponentID = 15 (index 15 from z[]), lengthof(all below)
ElementIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c) ComponentIDof(c), lengthof(c), valueof(c)
Note the holes in the elements 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 elements 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 attributes 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
elements 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
table2: type array, ID = 4 table2: type array, ID = 4
elements are: components are:
j1, type u32, ID = 1 j1, type u32, ID = 1
j2, type u32, ID = 2 j2, type u32, ID = 2
KEY: akey, ID = 1, V = { j1,j2 } KEY: akey, ID = 1, V = { j1,j2 }
table3: type array, ID = 5 table3: type array, ID = 5
elements are: components are:
someid, type u32, ID = 1 someid, type u32, ID = 1
name, type string variable sized, ID = 2 name, type string variable sized, ID = 2
table4: type array, ID = 6 table4: type array, ID = 6
elements are: components are:
j1, type u32, ID = 1 j1, type u32, ID = 1
j2, type u32, ID = 2 j2, type u32, ID = 2
j3, type u32, ID = 3 j3, type u32, ID = 3
j4, type u32, ID = 4 j4, type u32, ID = 4
KEY: mykey, ID = 1, V = { j1} KEY: mykey, ID = 1, V = { j1}
table5: type array, ID = 7 table5: type array, ID = 7
elements are: components are:
p1, type u32, ID = 1 p1, type u32, ID = 1
p2, type array, ID = 2, array elements 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 attribute 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.
skipping to change at page 116, line 23 skipping to change at page 116, line 23
KEYINFO TLV: {KeyID =1 KEY_DATA=100,200} KEYINFO TLV: {KeyID =1 KEY_DATA=100,200}
Result: Result:
If (j1=100, j2=200) was at entry 15: If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV OPER = DELETE-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0 IDCount = 2, IDs=4.15 flags = 0 IDCount = 2, IDs=4.15
RESULT-TLV RESULT-TLV
12. Dump contents of table3. It should be noted that this table has 12. Dump contents of table3. It should be noted that this table has
a column with element name that is variable sized. The purpose a column with component name that is variable sized. The
of this use case is to show how such an element is to be purpose of this use case is to show how such an component is to
encoded. be encoded.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = 0 IDCount = 1, IDs=5 flags = 0 IDCount = 1, IDs=5
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0 IDCount = 1, IDs=5 flags = 0 IDCount = 1, IDs=5
FULLDATA TLV, Length = XXXX FULLDATA TLV, Length = XXXX
skipping to change at page 121, line 24 skipping to change at page 121, line 24
Path-data-TLV Path-data-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11 flag = 0, IDCount=5, IDS = 7.10.2.11
Path-data TLV Path-data TLV
flags = 0 IDCount = 1, IDS = 2 flags = 0 IDCount = 1, IDS = 2
FULLDATA TLV: L=XXXX, V = valueof(x2) FULLDATA TLV: L=XXXX, V = valueof(x2)
17. Further example of manipulating a table of tables 17. Further example of manipulating a table of tables
Consider table 6 which is defined as: Consider table 6 which is defined as:
table6: type array, ID = 8 table6: type array, ID = 8
elements are: components are:
p1, type u32, ID = 1 p1, type u32, ID = 1
p2, type array, ID = 2, array elements of type type-A p2, type array, ID = 2, array components of type type-A
type-A: type-A:
a1, type u32, ID 1, a1, type u32, ID 1,
a2, type array ID2 ,array elements of type type-B a2, type array ID2 ,array components of type type-B
type-B: type-B:
b1, type u32, ID 1 b1, type u32, ID 1
b2, type u32, ID 2 b2, type u32, ID 2
If for example one wanted to set by replacing: If for example one wanted to set by replacing:
table6.10.p1 to 111 table6.10.p1 to 111
table6.10.p2.20.a1 to 222 table6.10.p2.20.a1 to 222
table6.10.p2.20.a2.30.b1 to 333 table6.10.p2.20.a2.30.b1 to 333
 End of changes. 59 change blocks. 
84 lines changed or deleted 86 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/