draft-ietf-forces-protocol-15.txt   draft-ietf-forces-protocol-16.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: February 26, 2009 IBM Expires: March 20, 2009 IBM
J. Hadi Salim (Ed.) J. Hadi Salim (Ed.)
Znyx Znyx
H. Khosravi (Ed.) H. Khosravi (Ed.)
Intel Intel
W. M. Wang (Ed.) W. M. Wang (Ed.)
Zhejiang Gongshang University Zhejiang Gongshang University
August 25, 2008
September 16, 2008
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-15.txt draft-ietf-forces-protocol-16.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 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 February 26, 2009. This Internet-Draft will expire on March 20, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies the Forwarding and Control Element Separation This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications (ForCES) protocol. ForCES protocol is used for communications
between Control Elements(CEs) and Forwarding Elements (FEs) in a between Control Elements(CEs) and Forwarding Elements (FEs) in a
ForCES Network Element (ForCES NE). This specification is intended ForCES Network Element (ForCES NE). This specification is intended
to meet the ForCES protocol requirements defined in RFC3654. Besides to meet the ForCES protocol requirements defined in RFC3654. Besides
the ForCES protocol messages, the specification also defines the the ForCES protocol, this specification also defines the requirements
framework, the mechanisms, and the Transport Mapping Layer (TML) for the Transport Mapping Layer (TML).
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). Special acknowledgement goes to (Zhejiang Gongshang University). Special acknowledgement goes to
skipping to change at page 3, line 25 skipping to change at page 3, line 25
between the model and this protocol specification. Without his between the model and this protocol specification. Without his
participation and persistence, this specification might never have participation and persistence, this specification might never have
been completed. been completed.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Other Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 11
4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 14
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 15
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 16
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 17
4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 19
4.3.1. Transactions, Atomicity, Execution and Responses . . 20 4.3.1. Transactions, Atomicity, Execution and Responses . . 19
4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 26
4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 26
4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 27
4.4.1. Association Setup State . . . . . . . . . . . . . . . 28 4.4.1. Association Setup State . . . . . . . . . . . . . . . 27
4.4.2. Association Established state or Steady State . . . . 29 4.4.2. Association Established state or Steady State . . . . 28
5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 31
5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 33 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 32
6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 34 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 33
6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 34 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 33
6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 39 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 38
6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 40 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 39
6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 40 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 39
6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4. Important Protocol encapsulations . . . . . . . . . . . . 41 6.4. Important Protocol encapsulations . . . . . . . . . . . . 40
6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 41 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 40
6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 42 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 41
6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 42 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 41
6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 42 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 41
7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 44 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 43
7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 48 7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 47
7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 48 7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 47
7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 48 7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 47
7.1.3. Relation of operational flags with global message 7.1.3. Relation of operational flags with global message
flags . . . . . . . . . . . . . . . . . . . . . . . . 49 flags . . . . . . . . . . . . . . . . . . . . . . . . 48
7.1.4. Content Path Selection . . . . . . . . . . . . . . . 49 7.1.4. Content Path Selection . . . . . . . . . . . . . . . 48
7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 49 7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 48
7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 50 7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 49
7.1.7. Result TLV . . . . . . . . . . . . . . . . . . . . . 52 7.1.7. RESULT TLV . . . . . . . . . . . . . . . . . . . . . 51
7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 55 7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 54
7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 56 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 55
7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 57 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 56
7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 60 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 59
7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 61 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 60
7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 64 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 63
7.4. Semantics of Message Direction . . . . . . . . . . . . . 64 7.4. Semantics of Message Direction . . . . . . . . . . . . . 63
7.5. Association Messages . . . . . . . . . . . . . . . . . . 65 7.5. Association Messages . . . . . . . . . . . . . . . . . . 64
7.5.1. Association Setup Message . . . . . . . . . . . . . . 65 7.5.1. Association Setup Message . . . . . . . . . . . . . . 64
7.5.2. Association Setup Response Message . . . . . . . . . 67 7.5.2. Association Setup Response Message . . . . . . . . . 66
7.5.3. Association Teardown Message . . . . . . . . . . . . 68 7.5.3. Association Teardown Message . . . . . . . . . . . . 67
7.6. Configuration Messages . . . . . . . . . . . . . . . . . 70 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 69
7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 70 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 69
7.6.2. Config Response Message . . . . . . . . . . . . . . . 72 7.6.2. Config Response Message . . . . . . . . . . . . . . . 71
7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 74 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 73
7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 74 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 73
7.7.2. Query Response Message . . . . . . . . . . . . . . . 76 7.7.2. Query Response Message . . . . . . . . . . . . . . . 75
7.8. Event Notification Message . . . . . . . . . . . . . . . 78 7.8. Event Notification Message . . . . . . . . . . . . . . . 77
7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 80 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 79
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 . . . . . . . . . . . . . . . . . . . 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88
9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 88 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 88
9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 88 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 88
9.1.2. Message authentication . . . . . . . . . . . . . . . 89 9.1.2. Message Authentication . . . . . . . . . . . . . . . 89
9.2. ForCES PL and TML security service . . . . . . . . . . . 89 9.2. ForCES PL and TML security service . . . . . . . . . . . 89
9.2.1. Endpoint authentication service . . . . . . . . . . . 89 9.2.1. Endpoint authentication service . . . . . . . . . . . 89
9.2.2. Message authentication service . . . . . . . . . . . 89 9.2.2. Message authentication service . . . . . . . . . . . 89
9.2.3. Confidentiality service . . . . . . . . . . . . . . . 89 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 89
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
11.1. Normative References . . . . . . . . . . . . . . . . . . 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 91
11.2. Informational References . . . . . . . . . . . . . . . . 91 11.2. Informational References . . . . . . . . . . . . . . . . 91
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92
skipping to change at page 6, line 15 skipping to change at page 6, line 15
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Other Notation 1.2. Other Notation
In table Table 1 and table Table 2 the following notation is used to In Table 1 and Table 2 the following notation is used to indicate
indicate multiplicity: multiplicity:
(value)+ .... means "1 or more instance of value" (value)+ .... means "1 or more instance of value"
(value)* .... means "0 or more instance of value" (value)* .... means "0 or more instance of value"
2. Introduction 2. Introduction
Forwarding and Control Element Separation (ForCES) defines an Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding information exchange between the control plane and the forwarding
skipping to change at page 7, line 30 skipping to change at page 7, line 30
components, 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
messages. A discussion of service primitives that must be provided
by the underlying transport interface will be discussed in a future
document.
Section 3 provides a glossary of terminology used in the Section 3 provides a glossary of terminology used in the
specification. specification.
Section 4 provides an overview of the protocol, including a Section 4 provides an overview of the protocol, including a
discussion on the protocol framework, descriptions of the Protocol discussion on the protocol framework, descriptions of the Protocol
Layer (PL) and a Transport Mapping Layer (TML), as well as of the Layer (PL) and a Transport Mapping Layer (TML), as well as of the
ForCES protocol mechanisms. Section 4.4 describes several Protocol ForCES protocol mechanisms. Section 4.4 describes several Protocol
scenarios and includes message exchange descriptions. scenarios and includes message exchange descriptions.
While this document does not define the TML, Section 5 details the While this document does not define the TML, Section 5 details the
skipping to change at page 10, line 8 skipping to change at page 9, line 8
entities such as FEs. entities such as FEs.
ForCES Network Element (NE) - An entity composed of one or more CEs ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside an NE, the NE represents a and one or more FEs. To entities outside an NE, the NE represents a
single point of management. Similarly, an NE usually hides its single point of management. Similarly, an NE usually hides its
internal organization from external entities. internal organization from external entities.
High Touch Capability - This term will be used to apply to the High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents capabilities found in some forwarders to take action on the contents
or headers of a packet based on content other than what is found in or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT, the IP header. Examples of these capabilities include quality of
firewall, and L7 content recognition. service policies, virtual private networks, firewall, and L7 content
recognition.
Inter-FE Topology - See FE Topology. Inter-FE Topology - See FE Topology.
Intra-FE Topology - See LFB Topology. Intra-FE Topology - See LFB Topology.
LFB (Logical Function Block) - The basic building block that is LFB (Logical Function Block) - The basic building block that is
operated on by the ForCES protocol. The LFB is a well defined, operated on by the ForCES protocol. The LFB is a well defined,
logically separable functional block that resides in an FE and is logically separable functional block that resides in an FE and is
controlled by the CE via ForCES protocol. The LFB may reside at the controlled by the CE via ForCES protocol. The LFB may reside at the
FE's datapath and process packets or may be purely an FE control or FE's datapath and process packets or may be purely an FE control or
skipping to change at page 11, line 17 skipping to change at page 10, line 19
and a CE Manager are determining which FE(s) and CE(s) should be part and a CE Manager are determining which FE(s) and CE(s) should be part
of the same network element. of the same network element.
Post-association Phase - The period of time during which an FE knows Post-association Phase - The period of time during which an FE knows
which CE is to control it and vice versa. This includes the time which CE is to control it and vice versa. This includes the time
during which the CE and FE are establishing communication with one during which the CE and FE are establishing communication with one
another. another.
ForCES Protocol - While there may be multiple protocols used within ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" and the overall ForCES architecture, the term "ForCES protocol" and
"protocol" refer to the Fp reference point in the ForCES Framework in "protocol" refer to the Fp reference points in the ForCES Framework
[RFC3746]. This protocol does not apply to CE-to-CE communication, in [RFC3746]. This protocol does not apply to CE-to-CE
FE-to-FE communication, or to communication between FE and CE communication, FE-to-FE communication, or to communication between FE
managers. Basically, the ForCES protocol works in a master-slave and CE managers. Basically, the ForCES protocol works in a master-
mode in which FEs are slaves and CEs are masters. This document slave mode in which FEs are slaves and CEs are masters. This
defines the specifications for this ForCES protocol. document defines the specifications for this ForCES protocol.
ForCES Protocol Layer (ForCES PL) - A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) - A layer in the ForCES protocol
architecture that defines the ForCES protocol messages, the protocol architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML as shown below). itself (including requirements of ForCES TML as shown below).
Specifications of ForCES PL are defined by this document. Specifications of ForCES PL are defined by this document.
ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
ForCES protocol architecture that uses the capabilities of existing ForCES protocol architecture that uses the capabilities of existing
transport protocols to specifically address protocol message transport protocols to specifically address protocol message
transportation issues, such as how the protocol messages are mapped transportation issues, such as how the protocol messages are mapped
to different transport media (like TCP, IP, ATM, Ethernet, etc), and to different transport media (like TCP, IP, ATM, Ethernet, etc), and
skipping to change at page 12, line 51 skipping to change at page 11, line 51
Fp: CE-FE interface Fp: CE-FE interface
Fi: FE-FE interface Fi: FE-FE interface
Fr: CE-CE interface Fr: CE-CE interface
Fc: Interface between the CE Manager and a CE Fc: Interface between the CE Manager and a CE
Ff: Interface between the FE Manager and an FE Ff: Interface between the FE Manager and an FE
Fl: Interface between the CE Manager and the FE Manager Fl: Interface between the CE Manager and the FE Manager
Fi/f: FE external interface Fi/f: FE external interface
Figure 1: ForCES Architectural Diagram Figure 1: ForCES Architectural Diagram
The ForCES protocol domain is found in the Fp Reference Point. The The ForCES protocol domain is found in the Fp Reference Points. The
Protocol Element configuration reference points, Fc and Ff also play Protocol Element configuration reference points, Fc and Ff also play
a role in the booting up of the ForCES Protocol. The protocol a role in the booting up of the ForCES Protocol. The protocol
element configuration (indicated by reference points Fc, Ff, and Fl element configuration (indicated by reference points Fc, Ff, and Fl
in [RFC3746] ) is out of scope of the ForCES protocol but is touched in [RFC3746] ) is out of scope of the ForCES protocol but is touched
on in this document in discussion of FEM and CEM since it is an on in this document in discussion of FEM and CEM since it is an
integral part of the protocol pre-association phase. integral part of the protocol pre-association phase.
Figure 2 below shows further breakdown of the Fp interface by example Figure 2 below shows further breakdown of the Fp interfaces by means
of an MPLS QoS enabled Network Element. of the example of an MPLS QoS enabled Network Element.
------------------------------------------------- -------------------------------------------------
| | | | | | | | | | | | | |
|OSPF |RIP |BGP |RSVP |LDP |. . . | |OSPF |RIP |BGP |RSVP |LDP |. . . |
| | | | | | | | | | | | | |
------------------------------------------------- CE ------------------------------------------------- CE
| ForCES Interface | | ForCES Interface |
------------------------------------------------- -------------------------------------------------
^ ^ ^ ^
| | | |
skipping to change at page 15, line 43 skipping to change at page 14, line 43
detailed description on how the FEM and CEM could be used. The pre- detailed description on how the FEM and CEM could be used. The pre-
association phase, where the CEM and FEM can be used, are described association phase, where the CEM and FEM can be used, are described
briefly in Section 4.2.1. briefly in Section 4.2.1.
An example of typical things the FEM/CEM could configure would be TML An example of typical things the FEM/CEM could configure would be TML
specific parameterizations such as: specific parameterizations such as:
a. How the TML connection should happen (for example what IP a. How the TML connection should happen (for example what IP
addresses to use, transport modes etc); addresses to use, transport modes etc);
b. The ID for the FE or CE (which would also be issued during the b. The ID for the FE (FEID) or CE (CEID) (which would also be issued
pre-association phase). during the pre-association phase).
c. Security parameterization such as keys etc. c. Security parameterization such as keys etc.
d. Connection association parameters d. Connection association parameters
Example of connection association parameters this might be: Example of connection association parameters this might be:
o simple parameters: send up to 3 association messages every 1 o simple parameters: send up to 3 association messages every 1
second second
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 post-association phase where the ForCES
operates to manipulate the parameters of the FEs. protocol operates to manipulate the parameters of the FEs.
CE sends Association Setup CE sends Association Setup
+---->--->------------>---->---->---->------->----+ +---->--->------------>---->---->---->------->----+
| Y | Y
^ | ^ |
| Y | Y
+---+-------+ +-------------+ +---+-------+ +-------------+
|FE Pre- | | FE | |FE Pre- | | FE |
|Association| CE sends Association Teardown | Associated | |Association| CE sends Association Teardown | Associated |
|Phase |<------- <------<-----<------<-------+ | |Phase |<------- <------<-----<------<-------+ |
| | | | | | | |
+-----------+ +-------------+ +-----------+ +-------------+
^ Y ^ Y
| | | |
+-<---<------<-----<------<----<---------<------+ +-<---<------<-----<------<----<---------<------+
FE loses association FE loses association
Figure 4: The FE State Machine Figure 4: The FE Protocol Phases
In the mandated case, once associated, the FE may forward packets In the mandated case, once associated, the FE may forward packets
depending on the configuration of its specific LFBs. An FE which is depending on the configuration of its specific LFBs. An FE which is
associated to a CE will continue sending packets until it receives an associated to a CE will continue sending packets until it receives an
Association teardown message or until it loses association. An Association teardown message or until it loses association. An
unassociated FE MAY continue sending packets when it is capable high unassociated FE MAY continue sending packets when it has a high
availability. The extra details are explained in Section 8 and not availability capability. The extra details are explained in
discussed here to allow for a clear explanation of the basics. Section 8 and not discussed here to allow for a clear explanation of
the basics.
The FE state transitions are controlled by means of the FE Object LFB The FE state transitions are controlled by means of the FE Object LFB
FEState component, which is defined in [FE-MODEL] and also explained FEState component, which is defined in [FE-MODEL] section 5.1 and
in Section 7.3.2. also explained in Section 7.3.2.
The FE initializes in the FEState OperDisable. When the FE is ready The FE initializes in the FEState OperDisable. When the FE is ready
to process packets in the data path it transitions itself to the to process packets in the data path it transitions itself to the
OperEnable state. OperEnable state.
The CE may decide to pause the FE after it already came up as The CE may decide to pause the FE after it already came up as
OperEnable. It does this by setting the FEState to AdminDisable. OperEnable. It does this by setting the FEState to AdminDisable.
The FE stays in the AdminDisable state until it is explicitly The FE stays in the AdminDisable state until it is explicitly
configured by the CE to transition to the OperEnable. configured by the CE to transition to the OperEnable state.
When the FE loses its association with the CE it may go into the pre- When the FE loses its association with the CE it may go into the pre-
association phase depending on the programmed policy. For the FE to association phase depending on the programmed policy. For the FE to
properly complete the transition to the AdminDisable state, it MUST properly complete the transition to the AdminDisable state, it MUST
stop Packet forwarding and this may impact multiple LFBS. How this stop Packet forwarding and this may impact multiple LFBS. How this
is achieved is outside the scope of this specification. is achieved is outside the scope of this specification.
4.2.1. Pre-association 4.2.1. Pre-association
The ForCES interface is configured during the pre-association phase. The ForCES interface is configured during the pre-association phase.
In a simple setup, the configuration is static and is read from a In a simple setup, the configuration is static and is typically read
saved configuration file. All the parameters for the association from a saved configuration file. All the parameters for the
phase are well known after the pre-association phase is complete. A association phase are well known after the pre-association phase is
protocol such as DHCP may be used to retrieve the configuration complete. A protocol such as DHCP may be used to retrieve the
parameters instead of reading them from a static configuration file. configuration parameters instead of reading them from a static
Note, this will still be considered static pre-association. Dynamic configuration file. Note, this will still be considered static pre-
configuration may also happen using the Fc, Ff and Fl reference association. Dynamic configuration may also happen using the Fc, Ff
points (refer to [RFC3746]). Vendors may use their own proprietary and Fl reference points (refer to [RFC3746]). Vendors may use their
service discovery protocol to pass the parameters. Essentially, only own proprietary service discovery protocol to pass the parameters.
guidelines are provided here and the details are left to the Essentially, only guidelines are provided here and the details are
implementation. left to the implementation.
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
skipping to change at page 18, line 32 skipping to change at page 17, line 34
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
capability discovery may be complete. Both the FE and CE would have capability discovery may be complete. Both the FE and CE would have
the necessary information for connecting to each other for the necessary information for connecting to each other for
configuration, accounting, identification, and authentication configuration, accounting, identification, and authentication
purposes. To summarize, at the completion of this stage both sides purposes. To summarize, at the completion of this stage both sides
have all the necessary protocol parameters such as timers, etc. The have all the necessary protocol parameters such as timers, etc. The
Fl reference point may continue to operate during the association Fl reference point may continue to operate during the association
phase and may be used to force a disassociation of an FE or CE. phase and may be used to force a disassociation of an FE or CE. The
Because the pre-association phase is out of scope, these details are specific interactions of the CEM and the FEM that are part of the
not discussed any further in this specification. The reader is pre-association phase are out of scope; for this reason these details
are not discussed any further in this specification. The reader is
referred to the framework document [RFC3746] for a slightly more referred to the framework document [RFC3746] for a slightly more
detailed discussion. detailed discussion.
4.2.2. Post-association 4.2.2. Post-association
In this phase, the FE and CE components communicate with each other In this phase, the FE and CE components communicate with each other
using the ForCES protocol (PL over TML) as defined in this document. using the ForCES protocol (PL over TML) as defined in this document.
There are three sub-phases: There are three sub-phases:
o Association Setup Stage o Association Setup Stage
skipping to change at page 20, line 43 skipping to change at page 19, line 44
4.3.1.1. Execution 4.3.1.1. Execution
There are 3 execution modes that can be requested for a batch of There are 3 execution modes that can be requested for a batch of
operations spanning one or more LFB selectors (refer to operations spanning one or more LFB selectors (refer to
Section 7.1.5) in one protocol message. The EM flag defined in the Section 7.1.5) in one protocol message. The EM flag defined in the
Common Header Section 6.1 selects the execution mode for a protocol Common Header Section 6.1 selects the execution mode for a protocol
message, as below: message, as below:
a. execute-all-or-none a. execute-all-or-none
b. execute-until-failure b. continue-execute-on-failure
c. continue-execute-on-failure c. execute-until-failure
4.3.1.1.1. execute-all-or-none 4.3.1.1.1. execute-all-or-none
When set to this mode of execution, independent operations in a When set to this mode of execution, independent operations in a
message MAY be targeted at one or more LFB selectors within an FE. message MAY be targeted at one or more LFB selectors within an FE.
All these operations are executed serially and the FE MUST have no All these operations are executed serially and the FE MUST have no
execution failure for any of the operations. If any operation fails execution failure for any of the operations. If any operation fails
to execute, then all the previous ones that have been executed prior to execute, then all the previous ones that have been executed prior
to the failure will need to be undone. I.e., there is rollback for to the failure will need to be undone. I.e., there is rollback for
this mode of operation. this mode of operation.
skipping to change at page 23, line 24 skipping to change at page 22, line 27
commit a transaction. When used with an ABT TP flag, the COMMIT commit a transaction. When used with an ABT TP flag, the COMMIT
operation signals the FE(s) to rollback (i.e un-COMMIT) a previously operation signals the FE(s) to rollback (i.e un-COMMIT) a previously
committed transaction. committed transaction.
The TRCOMP operation is a small addition to the classical 2PC The TRCOMP operation is a small addition to the classical 2PC
approach. TRCOMP is sent by the CE to signal the FE(s) that the approach. TRCOMP is sent by the CE to signal the FE(s) that the
transaction they have COMMITed is now over. This allows the FE(s) an transaction they have COMMITed is now over. This allows the FE(s) an
opportunity to clear state they may have kept around to perform a opportunity to clear state they may have kept around to perform a
rollback (if it became necessary). rollback (if it became necessary).
A transaction operation is started with a message the TP flag is set A transaction operation is started with a message in which the TP
to Start of Transaction (SOT). Multi-part messages, after the first flag is set to Start of Transaction (SOT). Multi-part messages,
one, are indicated by the Middle of Transaction flag (MOT). All after the first one, are indicated by the Middle of Transaction flag
messages from the CE MUST set the AlwaysACK flag (Section 6) to (MOT). All messages from the CE MUST set the AlwaysACK flag
solicit responses from the FE(s). (Section 6) to solicit responses from the FE(s).
Before the CE issues a commit (described further below) the FE MUST Before the CE issues a commit (described further below) the FE MUST
only validate that the operation can be executed but not execute it. only validate that the operation can be executed but not execute it.
Any failure notified by an FE causes the CE to abort the Any failure notified by an FE causes the CE to abort the
transaction on all FEs involved in the transaction. This is transaction on all FEs involved in the transaction. This is
achieved by sending a Config message with an ABT flag and a COMMIT achieved by sending a Config message with an ABT flag and a COMMIT
operation. operation.
If there are no failures by any participating FE, the transaction If there are no failures by any participating FE, the transaction
skipping to change at page 40, line 22 skipping to change at page 39, line 22
octets), and the length of the TLV data found in the octets), and the length of the TLV data found in the
value field, in octets. Note that this length is value field, in octets. Note that this length is
the actual length of the value, before any padding the actual length of the value, before any padding
for alignment is added. for alignment is added.
TLV Value (variable): TLV Value (variable):
The TLV value field carries the data. For The TLV value field carries the data. For
extensibility, the TLV value may in fact be a TLV. extensibility, the TLV value may in fact be a TLV.
Padding is required when the length is not a Padding is required when the length is not a
multiple of 32 bits, and is the minimum number of multiple of 32 bits, and is the minimum number of
bytes required to bring the TLV to a multiple of 32 octets required to bring the TLV to a multiple of 32
bits. The length of the value before padding is bits. The length of the value before padding is
indicated by the TLV Length field. Note: The value indicated by the TLV Length field. Note: The value
field could be empty which implies the minimal field could be empty which implies the minimal
length a TLV could be is 4 (length of "T" field and length a TLV could be is 4 (length of "T" field and
length of "L" field). length of "L" field).
6.2.1. Nested TLVs 6.2.1. Nested TLVs
TLV values can be other TLVs. This provides the benefits of protocol TLV values can be other TLVs. This provides the benefits of protocol
flexibility (being able to add new extensions by introducing new TLVs flexibility (being able to add new extensions by introducing new TLVs
skipping to change at page 40, line 48 skipping to change at page 39, line 48
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 component ("T") to be a 32-bit local index that refers to a ForCES component
ID. (refer to Section 6.4.1). The Length part of the ILV is fixed at ID. (refer to Section 6.4.1).
32 bits.
ILV length field is 4 octets, and includes the length of the ILV type
(4 octets), ILV Length (4 octets), and the length of the ILV data
found in the value field, in octets. Note that, as in the case of
the TLV, this length is the actual length of the value, before any
padding for alignment is added.
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 32 skipping to change at page 40, line 35
6.4. Important Protocol encapsulations 6.4. Important Protocol encapsulations
In this section, we review a few encapsulation concepts that are used In this section, we review a few encapsulation concepts that are used
by the ForCES protocol for its operations. by the ForCES protocol for its operations.
We briefly re-introduce two concepts, Paths and Keys, from the model We briefly re-introduce two concepts, Paths and Keys, from the model
draft [FE-MODEL] in order to provide context. The reader is referred draft [FE-MODEL] in order to provide context. The reader is referred
to [FE-MODEL] for a lot of the finer details. to [FE-MODEL] for a lot of the finer details.
For readability reasons, we introduce the encapsulation schemes that For readability reasons, we introduce the encapsulation schemes that
are used to carry content in a protocol message, namely FULLDATA, are used to carry content in a protocol message, namely FULLDATA-TLV,
SPARSEDATA, and RESULT TLVs. SPARSEDATA-TLV, and RESULT-TLV.
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
skipping to change at page 42, line 16 skipping to change at page 41, line 20
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
that uses the IP address and prefix length to uniquely reference an that uses the IP address and prefix length to uniquely reference an
IPv4 routing table row. In essence, while the common scheme to IPv4 routing table row. In essence, while the common scheme to
address a table row is via its table index, a table row's path could address a table row is via its table index, a table row's path could
be derived from a key. The KEYINFO TLV (Section 7) is used to carry be derived from a key. The KEYINFO-TLV (Section 7) is used to carry
the data that is used to do the lookup. the data that is used to do the lookup.
6.4.3. DATA TLVs 6.4.3. DATA TLVs
Data from or to the FE is carried in two types of TLVs: FULLDATA TLV Data from or to the FE is carried in two types of TLVs: FULLDATA-TLV
and SPARSEDATA TLV. Responses on operations executed by the FE are and SPARSEDATA-TLV. Responses to operations executed by the FE are
carried in RESULT TLVs. carried in RESULT-TLVs.
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 components. 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
an LFB type and instance is selected first. The LFB Selector is used an LFB type and instance is selected first. The LFB Selector is used
to select an LFB type and instance being targeted. Section to select an LFB type and instance being targeted. Section
(Section 7) goes into more details; for our purpose, we illustrate (Section 7) goes into more details; for our purpose, we illustrate
this concept using Figure 16 below. More examples of layouts can be this concept using Figure 16 below. More examples of layouts can be
skipping to change at page 44, line 14 skipping to change at page 43, line 14
7. Protocol Construction 7. Protocol Construction
A protocol layer PDU consists of a Common Header (defined in Section A protocol layer PDU consists of a Common Header (defined in Section
Section 6.1 ) and a message body. The Common Header is followed by a Section 6.1 ) and a message body. The Common Header is followed by a
message-type-specific message body. Each message body is formed from message-type-specific message body. Each message body is formed from
one or more top-level TLVs. A top-level TLV may contain one or more one or more top-level TLVs. A top-level TLV may contain one or more
sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs,
because they describe an operation to be done. because they describe an operation to be done.
+--------------+--------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
| Message Name | Top-Level | OPER-TLV(s) | Reference | | Message | Top-Level TLV | OPER-TLV(s) | Reference |
| | TLV | | | | Name | | | |
+--------------+--------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
| Association | (LFBselect)* | REPORT | Section 7.5.2 | | Association | (LFBselect)* | REPORT | Section 7.5.2 |
| Setup | | | | | Setup | | | |
| | | | | | | | | |
| Association | ASRresult | none | Section 7.5.2 | | Association | ASRresult-TLV | none | Section 7.5.2 |
| Setup | | | | | Setup | | | |
| Response | | | | | Response | | | |
| | | | | | | | | |
| Association | ASTreason | none | Section 7.5.3 | | Association | ASTreason-TLV | none | Section 7.5.3 |
| Teardown | | | | | Teardown | | | |
| | | | | | | | | |
| Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | DEL | COMMIT | | | | | | DEL | COMMIT | | |
| | | TRCOMP)+ | | | | | TRCOMP)+ | |
| | | | | | | | | |
| Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 | | Config | (LFBselect)+ | (SET-RESPONSE | | Section 7.6.2 |
| Response | | SET-PROP-RESPONSE | | | | Response | | SET-PROP-RESPONSE | | |
| | | DEL-RESPONSE | | | | | | DEL-RESPONSE | | |
| | | COMMIT-RESPONSE)+ | | | | | COMMIT-RESPONSE)+ | |
| | | | | | | | | |
| Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 |
| | | | | | | | | |
| Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 |
| Response | | GET-PROP-RESPONSE)+ | | | Response | | GET-PROP-RESPONSE)+ | |
| | | | | | | | | |
| Event | LFBselect | REPORT | Section 7.8 | | Event | LFBselect | REPORT | Section 7.8 |
| Notification | | | | | Notificatio | | | |
| n | | | |
| | | | | | | | | |
| Packet | REDIRECT-TLV | none | Section 7.9 | | Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | | | Redirect | | | |
| | | | | | | | | |
| Heartbeat | none | none | Section 7.10 | | Heartbeat | none | none | Section 7.10 |
+--------------+--------------+---------------------+---------------+ +-------------+---------------+---------------------+---------------+
Table 1 Table 1
The different messages are illustrated in Table 1. The different The different messages are illustrated in Table 1. The different
message type numerical values are defined in Appendix A.1. All the message type numerical values are defined in Appendix A.1. All the
TLVs values are defined in Appendix A.2. TLVs values are defined in Appendix A.2.
An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid
and LFB Instance being referenced as well as the OPER-TLV(s) being and LFB Instance being referenced as well as the OPER-TLV(s) being
applied to that reference. applied to that reference.
skipping to change at page 45, line 36 skipping to change at page 44, line 36
appearing components 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 component 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.
* IDcount(16 bit): count of 32 bit IDs * IDcount(16 bit): count of 32 bit IDs
* IDs: zero or more 32bit IDs (whose count is given by IDcount) * IDs: zero or more 32bit IDs (whose count is given by IDcount)
defining the main path. Depending on the flags, IDs could be defining the main path. Depending on the flags, IDs could be
field IDs only or a mix of field and dynamic IDs. Zero is used field IDs only or a mix of field and dynamic IDs. Zero is used
for the special case of using the entirety of the containing for the special case of using the entirety of the containing
context as the result of the path. context as the result of the path.
o SELECTOR is an optional construct that further defines the PATH. o SELECTOR is an optional construct that further defines the PATH.
Currently, the only defined selector is the KEYINFO-TLV, used for Currently, the only defined selector is the KEYINFO-TLV, used for
selecting an array entry by the value of a key field. The selecting an array entry by the value of a key field. The
presence of a SELECTOR is correct only when the flags also presence of a SELECTOR is correct only when the flags also
indicate its presence. A mismatch is a protocol format error. indicate its presence. A mismatch is a protocol format error.
o A KEYINFO TLV contains information used in content keying. o A KEYINFO-TLV contains information used in content keying.
* A KeyID is used in a KEYINFO TLV. It indicates which key for * A KeyID is used in a KEYINFO-TLV. It indicates which key for
the current array is being used as the content key for array the current array is being used as the content key for array
entry selection. entry selection.
* The key's data is the data to look for in the array, in the * The key's data is the data to look for in the array, in the
fields identified by the key field. The information is encoded fields identified by the key field. The information is encoded
according to the rules for the contents of a FULLDATA-TLV, and according to the rules for the contents of a FULLDATA-TLV, and
represent the field or fields which make up the key identified represent the field or fields which make up the key identified
by the KeyID. by the KeyID.
o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT TLV or 1 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1
or more further PATH-DATA selection. FULLDATA and SPARSEDATA are or more further PATH-DATA selection. FULLDATA-TLV and SPARSEDATA-
only allowed on SET or SET-PROP requests, or on responses which TLV are only allowed on SET or SET-PROP requests, or on responses
return content information (GET-RESPONSE for example). PATH-DATA which return content information (GET-RESPONSE for example).
may be included to extend the path on any request. PATH-DATA may be included to extend the path on any request.
* Note: Nested PATH-DATA TLVs are supported as an efficiency * Note: Nested PATH-DATA TLVs are supported as an efficiency
measure to permit common subexpression extraction. measure to permit common subexpression extraction.
* FULLDATA and SPARSEDATA contain "the data" whose path has been * FULLDATA-TLV and SPARSEDATA-TLV contain "the data" whose path
selected by the PATH. Refer to Section 7.1 for details. has been selected by the PATH. Refer to Section 7.1 for
details.
* The following table summarizes the applicability and * The following table summarizes the applicability and
restrictions of the FULL/SPARSEDATA TLV and the RESULT TLV to restrictions of the FULL/SPARSEDATA-TLVs and the RESULT-TLV to
the OPER-TLVs. the OPER-TLVs.
+-------------------+-------------------------------+---------------+ +-------------------+-------------------------------+---------------+
| OPER-TLV | DATA TLV | RESULT TLV | | OPER-TLV | DATA TLV | RESULT-TLV |
+-------------------+-------------------------------+---------------+ +-------------------+-------------------------------+---------------+
| SET | (FULLDATA-TLV | | none | | SET | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | | | | SPARSEDATA-TLV)+ | |
| | | | | | | |
| SET-PROP | (FULLDATA-TLV | | none | | SET-PROP | (FULLDATA-TLV | | none |
| | SPARSEDATA-TLV)+ | | | | SPARSEDATA-TLV)+ | |
| | | | | | | |
| SET-RESPONSE | none | (RESULT-TLV)+ | | SET-RESPONSE | none | (RESULT-TLV)+ |
| | | | | | | |
| SET-PROP-RESPONSE | none | (RESULT-TLV)+ | | SET-PROP-RESPONSE | none | (RESULT-TLV)+ |
skipping to change at page 47, line 42 skipping to change at page 46, line 42
| | | | | | | |
| COMMIT | none | none | | COMMIT | none | none |
| | | | | | | |
| COMMIT-RESPONSE | none | (RESULT-TLV)+ | | COMMIT-RESPONSE | none | (RESULT-TLV)+ |
| | | | | | | |
| TRCOMP | none | none | | TRCOMP | none | none |
+-------------------+-------------------------------+---------------+ +-------------------+-------------------------------+---------------+
Table 2 Table 2
o RESULT contains the indication of whether the individual SET or o RESULT-TLV contains the indication of whether the individual SET
SET-PROP succeeded. RESULT TLV is included on the assumption that or SET-PROP succeeded. RESULT-TLV is included on the assumption
individual parts of a SET request can succeed or fail separately. that individual parts of a SET request can succeed or fail
separately.
In summary this approach has the following characteristic: In summary this approach has the following characteristic:
o There can be one or more LFB class ID and instance ID combination o There can be one or more LFB class ID and instance ID combination
targeted in a message (batch) targeted in a message (batch)
o There can one or more operations on an addressed LFB class ID/ o There can one or more operations on an addressed LFB class ID/
instance ID combination (batch) instance ID combination (batch)
o There can be one or more path targets per operation (batch) o There can be one or more path targets per operation (batch)
o Paths may have zero or more data values associated (flexibility o Paths may have zero or more data values associated (flexibility
and operation specific) and operation specific)
It should be noted that the above is optimized for the case of a It should be noted that the above is optimized for the case of a
single LFB class ID and instance ID targeting. To target multiple single LFB class ID and instance ID targeting. To target multiple
instances within the same class, multiple LFBselects are needed. instances within the same class, multiple LFBselects are needed.
7.1. Discussion on encoding 7.1. Discussion on encoding
skipping to change at page 48, line 15 skipping to change at page 47, line 18
o Paths may have zero or more data values associated (flexibility o Paths may have zero or more data values associated (flexibility
and operation specific) and operation specific)
It should be noted that the above is optimized for the case of a It should be noted that the above is optimized for the case of a
single LFB class ID and instance ID targeting. To target multiple single LFB class ID and instance ID targeting. To target multiple
instances within the same class, multiple LFBselects are needed. instances within the same class, multiple LFBselects are needed.
7.1. Discussion on encoding 7.1. Discussion on encoding
Section 6.4.3 discusses the two types of DATA encodings (FULLDATA and Section 6.4.3 discusses the two types of DATA encodings (FULLDATA-TLV
SPARSEDATA TLV) and the justifications for their existence. In this and SPARSEDATA-TLV) and the justifications for their existence. In
section we explain how they are encoded. this section we explain how they are encoded.
7.1.1. Data Packing Rules 7.1.1. Data Packing Rules
The scheme for encoding data used in this doc adheres to the The scheme for encoding data used in this doc adheres to the
following rules: following rules:
o The Value ("V" of TLV) of FULLDATA TLV will contain the data being o The Value ("V" of TLV) of FULLDATA-TLV will contain the data being
transported. This data will be as was described in the LFB transported. This data will be as was described in the LFB
definition. definition.
o Variable sized data within a FULLDATA TLV will be encapsulated o Variable sized data within a FULLDATA-TLV will be encapsulated
inside another FULLDATA TLV inside the V of the outer TLV. For inside another FULLDATA-TLV inside the V of the outer TLV. For
example of such a setup refer to Appendix C and Appendix D example of such a setup refer to Appendix C and Appendix D
o In the case of FULLDATA TLVs: o In the case of FULLDATA-TLVs:
* When a table is referred to in the PATH (IDs) of a PATH-DATA- * When a table is referred to in the PATH (IDs) of a PATH-DATA-
TLV, then the FULLDATA's "V" will contain that table's row TLV, then the FULLDATA-TLV's "V" will contain that table's row
content prefixed by its 32 bit index/subscript. On the other content prefixed by its 32 bit index/subscript. On the other
hand, when PATH flags are 00, the PATH may contain an index hand, when PATH flags are 00, the PATH may contain an index
pointing to a row in table; in such a case, the FULLDATA's "V" pointing to a row in table; in such a case, the FULLDATA-TLV's
will only contain the content with the index in order to avoid "V" will only contain the content with the index in order to
ambiguity. avoid ambiguity.
7.1.2. Path Flags 7.1.2. Path Flags
The following flags are currently defined: The following flags are currently defined:
o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present
following this path information, and should be considered in following this path information, and should be considered in
evaluating the path. evaluating the path.
7.1.3. Relation of operational flags with global message flags 7.1.3. Relation of operational flags with global message flags
Global flags, such as the execution mode and the atomicity indicators Global flags, such as the execution mode and the atomicity indicators
defined in the header, apply to all operations in a message. Global defined in the header, apply to all operations in a message. Global
flags provide semantics that are orthogonal to those provided by the flags provide semantics that are orthogonal to those provided by the
operational flags, such as the flags defined in Path Data. The scope operational flags, such as the flags defined in Path Data. The scope
of operational flags is restricted to the operation. of operational flags is restricted to the operation.
7.1.4. Content Path Selection 7.1.4. Content Path Selection
The KEYINFO TLV describes the KEY as well as associated KEY data. The KEYINFO-TLV describes the KEY as well as associated KEY data.
KEYs, used for content searches, are restricted and described in the KEYs, used for content searches, are restricted and described in the
LFB definition. LFB definition.
7.1.5. LFBselect-TLV 7.1.5. LFBselect-TLV
The LFBselect TLV is an instance of a TLV as defined in Section 6.2. The LFBselect TLV is an instance of a TLV as defined in Section 6.2.
The definition is as below: The 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
skipping to change at page 51, line 9 skipping to change at page 50, line 9
7.1.6. OPER-TLV 7.1.6. OPER-TLV
The OPER-TLV is a place holder in the grammar for TLVs that define The OPER-TLV is a place holder in the grammar for TLVs that define
operations. The different types are defined in Table 3, below. operations. The different types are defined in Table 3, below.
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments | | OPER-TLV | TLV | Comments |
| | "Type" | | | | "Type" | |
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or add | | SET | 0x0001 | From CE to FE. Used to create or |
| | | or update attributes | | | | add or update attributes |
| | | | | | | |
| SET-PROP | 0x0002 | From CE to FE. Used to create or add | | SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | or update attribute properties | | | | add or update attribute properties |
| | | | | | | |
| SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry |
| | | response of a SET | | | | response of a SET |
| | | | | | | |
| SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry |
| | | response of a SET-PROP | | | | response of a SET-PROP |
| | | | | | | |
| DEL | 0x0005 | From CE to FE. Used to delete or | | DEL | 0x0005 | From CE to FE. Used to delete or |
| | | remove an attribute | | | | remove an attribute |
| | | | | | | |
skipping to change at page 52, line 8 skipping to change at page 51, line 8
| | | | | | | |
| TRCOMP | 0x000E | From CE to FE. Used to indicate | | TRCOMP | 0x000E | From CE to FE. Used to indicate |
| | | NE-wide success of 2PC transaction | | | | NE-wide success of 2PC transaction |
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
Table 3 Table 3
Different messages define OPER-TLV are valid and how they are used Different messages define OPER-TLV are valid and how they are used
(refer to Table 1 and Table 2). (refer to Table 1 and Table 2).
SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do
not carry RESULT TLVs. On the other hand, SET-RESPONSE, SET-PROP- not carry RESULT-TLVs. On the other hand, SET-RESPONSE, SET-PROP-
RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT TLVs. RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT-TLVs.
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-TLV or
in the original request will be replaced with a RESULT TLV in the SPARSEDATA-TLV in the original request will be replaced with a
response. If the request set the FailureACK flag, then only those RESULT-TLV in the response. If the request set the FailureACK flag,
items which failed will appear in the response. If the request was then only those items which failed will appear in the response. If
for AlwaysACK, then all components of the request will appear in the the request was for AlwaysACK, then all components of the request
response with RESULT TLVs. will appear in the 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-
issued, and some field in the structure is invalid, the FE will not TLV is issued, and some field in the structure is invalid, the FE
attempt to indicate which field was invalid, but rather will indicate will not attempt to indicate which field was invalid, but rather will
that the operation failed. Note further that if there are multiple indicate that the operation failed. Note further that if there are
errors in a single leaf PATH-DATA/FULLDATA, the FE can select which multiple errors in a single leaf PATH-DATA/FULLDATA-TLB, the FE can
error it chooses to return. So if a FULLDATA for a SET/SET-PROP of a select which error it chooses to return. So if a FULLDATA-TLV for a
structure attempts to write one field which is read only, and SET/SET-PROP of a structure attempts to write one field which is read
attempts to set another field to an invalid value, the FE can return only, and attempts to set another field to an invalid value, the FE
indication of either error. can return indication of either error.
A SET/SET-PROP operation on a variable length component 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 component or an optional structure component. 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-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved | | Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Result TLV Figure 19: RESULT TLV
Defined Result Values Defined Result Values
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
| Result Value | Value | Definition | | Result Value | Value | Definition |
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
| E_SUCCESS | 0x00 | Success | | E_SUCCESS | 0x00 | Success |
| | | | | | | |
| E_INVALID_HEADER | 0x01 | Unspecified error with | | E_INVALID_HEADER | 0x01 | Unspecified error with |
| | | header. | | | | header. |
| | | | | | | |
skipping to change at page 55, line 35 skipping to change at page 54, line 35
| | | | | | | |
| E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for |
| | | when the FE can not | | | | when the FE can not |
| | | 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-TLV and a 16-bit Length followed by
data value/contents. Likewise, a SPARSEDATA TLV has "T" = the data value/contents. Likewise, a SPARSEDATA-TLV has "T" =
SPARSEDATA, a 16-bit Length, followed by the data value/contents. In SPARSEDATA-TLV, a 16-bit Length, followed by the data value/contents.
the case of the SPARSEDATA, each component in the Value part of the In the case of the SPARSEDATA-TLV, each component in the Value part
TLV will be further encapsulated in an ILV. of the 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-TLV and SPARSEDATA-
Appendix C is very useful in illustrating these rules: TLVs. 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
component at that path level is present. In example 1(c) of component at that path level is present. In example 1(c) of
Appendix C this concept is illustrated by the presence of all Appendix C this concept is illustrated by the presence of all
components of the structure S in the FULLDATA TLV encoding. This components of the structure S in the FULLDATA-TLV encoding. This
requirement holds regardless of whether the fields are fixed or requirement holds regardless of whether the fields are fixed or
variable length, mandatory or optional. variable length, mandatory or optional.
* If a FULLDATA TLV is used, the encoder MUST lay out data for * If a FULLDATA-TLV is used, the encoder MUST lay out data for
each component in the same order in which the data was each component in the same order in which the data was
defined in the LFB specification. This ensures the decoder defined in the LFB specification. This ensures the decoder
is able to retrieve the data. To use the example 1 again in is able to retrieve the data. To use the example 1 again in
Appendix C, this implies the encoder/decoder is assumed to Appendix C, this implies the encoder/decoder is assumed to
have knowledge of how structure S is laid out in the have knowledge of how structure S is laid out in the
definition. definition.
* In the case of a SPARSEDATA, it does not need to be ordered * In the case of a SPARSEDATA-TLV, it does not need to be
since the "I" in the ILV uniquely identifies the component. ordered since the "I" in the ILV uniquely identifies the
Examples 1(a) and 1(b) illustrate the power of SPARSEDATA component. Examples 1(a) and 1(b) in Appendix C illustrate
encoding. the power of SPARSEDATA-TLV 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 * The values for atomic, variable-length fields are given
inside FULLDATA TLVs. inside FULLDATA-TLVs.
4. Inside a SPARSEDATA TLV 4. Inside a SPARSEDATA-TLV
* The values for atomic fields may be given with ILVs (32-bit * The values for atomic fields may be given with ILVs (32-bit
index, 32-bit length) index, 32-bit length)
5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 5. Any of the FULLDATA-TLVs can contain an ILV but an ILV cannot
contain a FULLDATA. This is because it is hard to disambiguate contain a FULLDATA-TLV. This is because it is hard to
ILV since an I is 32 bits and a T is 16 bits. disambiguate the 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-TLV can also contain a FULLDATA-TLV for variable sized
components. 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.
o It should be possible to take the same GET-RESPONSE and convert o It should be possible to take the same GET-RESPONSE and convert
it to a SET successfully by merely changing the T in the it to a SET successfully by merely changing the T in the
operational TLV. operational TLV.
o There are exceptions to this rule: o There are exceptions to this rule:
1. When a KEY selector is used with a path in a GET operation, 1. When a KEY selector is used with a path in a GET operation,
that selector is not returned in the GET-RESPONSE; instead that selector is not returned in the GET-RESPONSE; instead
the cooked result is returned. Refer to the examples using the cooked result is returned. Refer to the examples using
skipping to change at page 59, line 31 skipping to change at page 58, line 31
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| + -- T = KEYINFO | + -- T = KEYINFO-TLV
| | + -- KEY_ID | | + -- KEY_ID
| | + -- KEY_DATA | | + -- KEY_DATA
| | | |
| + -- T = FULLDATA | + -- T = FULLDATA-TLV
| + -- data | + -- data
| |
| |
T = SET T = SET
| | | |
| +- T = Path-data | +- T = Path-data
| | | | | |
| | + -- flags | | + -- flags
| | + -- IDCount | | + -- IDCount
| | + -- IDs | | + -- IDs
| | | | | |
| | + -- T = FULLDATA | | + -- T = FULLDATA-TLV
| | + -- data | | + -- data
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| | | |
| + -- T = FULLDATA | + -- T = FULLDATA-TLV
| + -- data | + -- data
T = DEL T = DEL
| |
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
| |
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
| |
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
+ -- T = KEYINFO + -- T = KEYINFO-TLV
| + -- KEY_ID | + -- KEY_ID
| + -- KEY_DATA | + -- KEY_DATA
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
Figure 21: Sample operation layout Figure 21: Sample operation layout
skipping to change at page 66, line 26 skipping to change at page 65, line 26
Only one operation type is defined for the association setup Only one operation type is defined for the association setup
message: message:
Type = "REPORT" - this type of operation is for FE to Type = "REPORT" - this type of operation is for FE to
report something to CE. report something to CE.
PATH-DATA-TLV for REPORT: PATH-DATA-TLV for REPORT:
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 PATH- in section (Section 7) in the PATH-DATA BNF definition. The PATH-
DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but
SHALL NOT contain any RESULT TLV in the data format. The RESULT SHALL NOT contain any RESULT-TLV in the data format. The RESULT-
TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in
Section 7.1.8. 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
format is shown below: format is shown below:
main hdr (type = Association Setup) main hdr (type = Association Setup)
| |
| |
+--- T = LFBselect +--- T = LFBselect
skipping to change at page 68, line 37 skipping to change at page 67, line 37
1 = FE ID invalid 1 = FE ID invalid
2 = permission denied 2 = permission denied
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:
main hdr (type = Association Setup Response) main hdr (type = Association Setup Response)
| |
| |
+--- T = ASResult +--- T = ASResult-TLV
Figure 25: PDU Format for Association Setup Repsonse Message Figure 25: PDU Format for Association Setup Repsonse Message
7.5.3. Association Teardown Message 7.5.3. Association Teardown Message
This message can be sent by the FE or CE to any ForCES element to end This message can be sent by the FE or CE to any ForCES element to end
its ForCES association with that element. its ForCES association with that element.
Message transfer direction: Message transfer direction:
CE to FE, or FE to CE (or CE to CE) CE to FE, or FE to CE (or CE to CE)
skipping to change at page 69, line 18 skipping to change at page 68, line 18
ignored by the receiver. ignored by the receiver.
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 = ASTreason | Length | | Type = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason | | Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: ASTreason TLV Figure 26: ASTreason-TLV
Type (16 bits): Type (16 bits):
The type of the TLV is "ASTreason". The type of the TLV is "ASTreason".
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in octets. Length of the TLV including the T and L fields, in octets.
Teardown Reason (32 bits): Teardown Reason (32 bits):
This indicates the reason why the association is being This indicates the reason why the association is being
terminated. Several reason codes are defined as follows. terminated. Several reason codes are defined as follows.
skipping to change at page 69, line 48 skipping to change at page 68, line 48
4 - error - application crash 4 - error - application crash
255 - error - other or unspecified 255 - error - other or unspecified
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:
main hdr (type = Association Teardown) main hdr (type = Association Teardown)
| |
| |
+--- T = ASTreason +--- T = ASTreason-TLV
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
skipping to change at page 71, line 20 skipping to change at page 70, line 20
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
header only). header only).
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-TLV BNF definition. The
restriction on the use of PATH-DATA-TLV for SET/SET-PROP restriction on the use of PATH-DATA-TLV for SET/SET-PROP
operation is that it MUST contain either a FULLDATA or SPARSEDATA operation is that it MUST contain either a FULLDATA-TLV or
TLV(s), but MUST NOT contain any RESULT TLV. The restriction on SPARSEDATA-TLV(s), but MUST NOT contain any RESULT-TLV. The
the use of PATH-DATA-TLV for DEL operation is it MAY contain restriction on the use of PATH-DATA-TLV for DEL operation is it
FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT MAY contain FULLDATA-TLV or SPARSEDATA-TLV(s), but MUST NOT
TLV. The RESULT TLV is defined in Section 7.1.7 and FULLDATA and contain any RESULT-TLV. The RESULT-TLV is defined in
SPARSEDATA TLVs is defined in Section 7.1.8. Section 7.1.7 and FULLDATA-TLV and SPARSEDATA-TLVs is defined in
Section 7.1.8.
*Note: For Event subscription, the events will be defined by the *Note: For Event subscription, the events will be defined by the
individual LFBs. individual LFBs.
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:
main hdr (type = Config) main hdr (type = Config)
| |
| |
skipping to change at page 72, line 19 skipping to change at page 71, line 19
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
. | . |
| |
+-- LFBInstance = target LFB instance +-- LFBInstance = target LFB instance
| |
| |
+-- T = operation { SET } +-- T = operation { SET }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| // associated with FULL or SPARSEDATA TLV(s) | // associated with FULLDATA-TLV or SPARSEDATA-TLV(s)
| |
+-- T = operation { DEL } +-- T = operation { DEL }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
. .
. .
Figure 29: PDU Format for Configuration Message Figure 29: PDU Format for Configuration Message
skipping to change at page 73, line 30 skipping to change at page 72, line 30
of SET operation of LFB components 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 component 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 components 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-TLV 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
operation is that it MUST contain RESULT TLV(s). The restriction operation is that it MUST contain RESULT-TLV(s). The restriction
on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also
MUST contain RESULT TLV(s). The RESULT TLV is defined in MUST contain RESULT-TLV(s). The RESULT-TLV is defined in
Section 7.1.7. Section 7.1.7.
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:
main hdr (type = ConfigResponse) main hdr (type = ConfigResponse)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
. | . |
| |
+-- LFBInstance = target LFB instance +-- LFBInstance = target LFB instance
| |
| |
+-- T = operation { SET-RESPONSE } +-- T = operation { SET-RESPONSE }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| // 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-TLV
Figure 31: PDU Format for 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 components, 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.
skipping to change at page 75, line 29 skipping to change at page 74, line 29
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
components. components.
Type = "GET-PROP" - this operation is to request to get Type = "GET-PROP" - this operation is to request to get
LFB components. 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-TLV 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-TLV or FULLDATA-
and RESULT TLV in the data format. TLV 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:
main hdr (type = Query) main hdr (type = Query)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
skipping to change at page 77, line 27 skipping to change at page 76, line 27
defined: defined:
Type = "GET-RESPONSE" - this operation is to response to Type = "GET-RESPONSE" - this operation is to response to
get operation of LFB components. 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 components. 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-TLV 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-TLVs
FULLDATA TLVs are defined in Section 7.1.8. and 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
format is shown below: format is shown below:
main hdr (type = QueryResponse) main hdr (type = QueryResponse)
| |
| |
+--- T = LFBselect +--- T = LFBselect
. | . |
. +-- LFBCLASSID = target LFB class . +-- LFBCLASSID = target LFB class
skipping to change at page 79, line 26 skipping to change at page 78, line 26
Type: Type:
Only one operation type is defined for the event notification Only one operation type is defined for the event notification
message: message:
Type = "REPORT" - this type of operation is for FE to Type = "REPORT" - this type of operation is for FE to
report something to CE. report something to CE.
PATH-DATA-TLV for REPORT: PATH-DATA-TLV for REPORT:
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 PATH- in section (Section 7) in the PATH-DATA-TLV BNF definition. The
DATA-TLV for REPORT operation MAY contain FULLDATA or SPARSEDATA PATH-DATA-TLV for REPORT operation MAY contain FULLDATA-TLV or
TLV(s) but MUST NOT contain any RESULT TLV in the data format. SPARSEDATA-TLV(s) but MUST NOT contain any 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:
main hdr (type = Event Notification) main hdr (type = Event Notification)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = target LFB class +-- LFBCLASSID = target LFB class
skipping to change at page 81, line 8 skipping to change at page 80, line 26
Figure 38: Redirect_Data TLV Figure 38: Redirect_Data TLV
Meta Data TLV: Meta Data TLV:
This is a TLV that specifies meta-data associated with followed This is a TLV that specifies meta-data associated with followed
redirected data. The TLV is as follows: redirected data. The TLV is as follows:
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 = METADATA | Length | | Type = METADATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: METADATA 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 82, line 8 skipping to change at page 81, line 28
Where, Meta Data ID is an identifier for the meta data, which is Where, Meta Data ID is an identifier for the meta data, which is
statically assigned by the LFB definition. statically assigned by the LFB definition.
Redirect Data TLV Redirect Data TLV
This is a TLV describing one packet of data to be directed via the This is a TLV describing one packet of data to be directed via the
redirect operation. The TLV format is as follows: redirect operation. The TLV format is as follows:
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 = REDIRECTDATA | Length | | Type = REDIRECTDATA-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data | | Redirected Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Redirect Data TLV Figure 41: Redirect Data TLV
Redirected Data: Redirected Data:
This field contains the packet that is to be redirected in network This field contains the packet that is to be redirected in network
byte order. The packet should be 32-bits aligned as is the data byte order. The packet should be 32-bits aligned as is the data
skipping to change at page 82, line 31 skipping to change at page 82, line 10
encapsulated encapsulated
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:
main hdr (type = PacketRedirect) main hdr (type = PacketRedirect)
| |
| |
+--- T = Redirect +--- T = Redirect
. | . |
. +-- T = METADATA . +-- T = METADATA-TLV
| | | |
| +-- Meta Data ILV | +-- Meta Data ILV
| | | |
| +-- Meta Data ILV | +-- Meta Data ILV
| . | .
| . | .
| |
+-- T = REDIRECTDATA +-- T = REDIRECTDATA-TLV
| |
+-- // Redirected Data +-- // Redirected Data
Figure 42: PDU Format for Packet Redirect Message Figure 42: PDU Format for Packet Redirect Message
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-
skipping to change at page 89, line 5 skipping to change at page 89, line 5
9.1.1. Endpoint Authentication 9.1.1. Endpoint Authentication
Each CE and FE PL maintains a list of associations as part its of Each CE and FE PL maintains a list of associations as part its of
configuration. This is done via the CEM and FEM interfaces. An FE configuration. This is done via the CEM and FEM interfaces. An FE
MUST connect to only those CEs that are configured via the FEM; MUST connect to only those CEs that are configured via the FEM;
similarly, a CE should accept the connection and establish similarly, a CE should accept the connection and establish
associations for the FEs which are configured via the CEM. The CE associations for the FEs which are configured via the CEM. The CE
should validate the FE identifier before accepting the connections should validate the FE identifier before accepting the connections
during the pre-association phase. during the pre-association phase.
9.1.2. Message authentication 9.1.2. Message Authentication
When a CE or FE initiates a message, the receiving endpoint MUST When a CE or FE initiates a message, the receiving endpoint MUST
validate the initiator of the message by checking the common header validate the initiator of the message by checking the common header
CE or FE identifiers. This will ensure proper protocol functioning. CE or FE identifiers. This will ensure proper protocol functioning.
This extra processing step is recommend even when underlying provides This extra processing step is recommended even when the underlying
TML layer security services exist. TML layer security services exist.
9.2. ForCES PL and TML security service 9.2. ForCES PL and TML security service
This section is applicable if an operator wishes to use the TML This section is applicable if an operator wishes to use the TML
security services. A ForCES TML MUST support one or more security security services. A ForCES TML MUST support one or more security
services such as endpoint authentication service, message services such as endpoint authentication service, message
authentication service, and confidentiality service, as part of TML authentication service, and confidentiality service, as part of TML
security layer functions. It is the responsibility of the operator security layer functions. It is the responsibility of the operator
to select an appropriate security service and configure security to select an appropriate security service and configure security
skipping to change at page 103, line 22 skipping to change at page 103, line 22
========== ==========
Structure with three fixed-lengthof, mandatory fields. Structure with three fixed-lengthof, mandatory fields.
struct S { struct S {
uint16 a uint16 a
uint16 b uint16 b
uint16 c uint16 c
} }
(a) Describing all fields using SPARSEDATA (a) Describing all fields using SPARSEDATA-TLV
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(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
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: Even though there are non-optional components in structure S, Note: Even though there are non-optional components in structure S,
since one can uniquely identify components, one can selectively send since one can uniquely identify components, one can selectively send
component 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)
========== ==========
Example 2: Example 2:
========== ==========
Structure with three fixed-lengthof fields, one mandatory, two Structure with three fixed-lengthof fields, one mandatory, two
optional. optional.
struct T { struct T {
uint16 a uint16 a
uint16 b (optional) uint16 b (optional)
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-TLV
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(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-TLV
Path-Data TLV Path-Data TLV
Path to an instance of S ... Path to an instance of S ...
SPARSEDATA TLV SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(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)
Note: FULLDATA TLV _cannot_ be used unless all fields are being Note: FULLDATA-TLV _cannot_ be used unless all fields are being
described. described.
========== ==========
Example 3: Example 3:
========== ==========
Structure with a mix of fixed-lengthof and variable-lengthof fields, Structure with a mix of fixed-lengthof and variable-lengthof fields,
some mandatory, some optional. Note in this case, b is variable some mandatory, some optional. Note in this case, b is variable
sized sized
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-TLV
Path to an instance of U ... Path to an instance of U ...
SPARSEDATA TLV SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(b), lengthof(b), valueof(b) ComponentIDof(b), lengthof(b), valueof(b)
ComponentIDof(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-TLV
Path to an instance of U ... Path to an instance of U ...
SPARSEDATA TLV SPARSEDATA-TLV
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
ComponentIDof(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 component b TLV within the outer FULLDATA-TLV as in the case of component b
above. 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
struct U z[] struct U z[]
} }
(a) Encoding using SPARSEDATA, with two instances of z[], also (a) Encoding using SPARSEDATA-TLV, with two instances of z[], also
described with SPARSEDATA, assuming only the 10th and 15th subscript described with SPARSEDATA-TLV, assuming only the 10th and 15th
of z[] are encoded. subscript of z[] are encoded.
path to instance of V ... path to instance of V ...
SPARSEDATA TLV SPARSEDATA-TLV
ComponentIDof(x), lengthof(x), valueof(x) ComponentIDof(x), lengthof(x), valueof(x)
ComponentIDof(y), lengthof(y), valueof(y) ComponentIDof(y), lengthof(y), valueof(y)
ComponentIDof(z), lengthof(all below) ComponentIDof(z), lengthof(all below)
ComponentID = 10 (i.e index 10 from z[]), lengthof(all below) ComponentID = 10 (i.e index 10 from z[]), lengthof(all below)
ComponentIDof(a), lengthof(a), valueof(a) ComponentIDof(a), lengthof(a), valueof(a)
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)
skipping to change at page 108, line 7 skipping to change at page 108, line 7
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 component 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-TLV for data encoding;
although SPARSEDATA would make more sense in certain occasions, the although SPARSEDATA-TLV would make more sense in certain occasions,
emphasis is on showing the message layout. Refer to Appendix C for the emphasis is on showing the message layout. Refer to Appendix C
examples that show usage of both FULLDATA and SPARSEDATA. for examples that show usage of both FULLDATA-TLV and SPARSEDATA-TLV.
1. To get foo1 1. To get foo1
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: IDCount = 1, IDs = 1 Path-data TLV: IDCount = 1, IDs = 1
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags=0, IDCount = 1, IDs = 1 flags=0, IDCount = 1, IDs = 1
FULLDATA-TLV L = 4+4, V = valueof(foo1) FULLDATA-TLV L = 4+4, V = valueof(foo1)
2. To set foo2 to 10 2. To set foo2 to 10
OPER = SET-TLV OPER = SET-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
FULLDATA TLV: L = 4+4, V=10 FULLDATA-TLV: L = 4+4, V=10
Result: Result:
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
RESULT-TLV RESULT-TLV
3. To dump table2 3. To dump table2
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
IDCount = 1, IDs = 4 IDCount = 1, IDs = 4
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
FULLDATA=TLV: L = XXX, V= FULLDATA-TLV: L = XXX, V=
a series of: index, valueof(j1), valueof(j2) a series of: index, valueof(j1), valueof(j2)
representing the entire table representing the entire table
Note: One should be able to take a GET-RESPONSE-TLV and Note: One should be able to take a GET-RESPONSE-TLV and
convert it to a SET-TLV. If the result in the above example convert it to a SET-TLV. If the result in the above example
is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV)
then the entire contents of the table will be replaced at then the entire contents of the table will be replaced at
that point. that point.
4. Multiple operations Example. To create entry 0-5 of table2 4. Multiple operations Example. To create entry 0-5 of table2
(Error conditions are ignored) (Error conditions are ignored)
skipping to change at page 113, line 26 skipping to change at page 113, line 26
9. Dump contents of table1. 9. Dump contents of table1.
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=3 flags = 0, IDCount = 1, IDs=3
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs=3 flags = 0, IDCount = 1, IDs=3
FULLDATA TLV, Length = XXXX FULLDATA-TLV, Length = XXXX
(depending on size of table1) (depending on size of table1)
index, valueof(t1),valueof(t2) index, valueof(t1),valueof(t2)
index, valueof(t1),valueof(t2) index, valueof(t1),valueof(t2)
. .
. .
. .
10. Using Keys. Get row entry from table4 where j1=100. Recall, j1 10. Using Keys. Get row entry from table4 where j1=100. Recall, j1
is a defined key for this table and its KeyID is 1. is a defined key for this table and its KeyID is 1.
skipping to change at page 114, line 7 skipping to change at page 114, line 7
KEYINFO-TLV = KeyID=1, KEY_DATA=100 KEYINFO-TLV = KeyID=1, KEY_DATA=100
Result: Result:
If j1=100 was at index 10 If j1=100 was at index 10
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=6.10 flags = 0, IDCount = 1, IDs=6.10
FULLDATA-TLV containing FULLDATA-TLV containing
valueof(j1), valueof(j2),valueof(j3),valueof(j4) valueof(j1), valueof(j2),valueof(j3),valueof(j4)
11. Delete row with KEY match (j1=100, j2=200) in table 2. Note 11. Delete row with KEY match (j1=100, j2=200) in table2. Note that
that the j1,j2 pair are a defined key for the table 2. the j1,j2 pair are a defined key for the table2.
OPER = DEL-TLV OPER = DEL-TLV
Path-data TLV: Path-data TLV:
flags = F_SELKEY IDCount = 1, IDs=4 flags = F_SELKEY IDCount = 1, IDs=4
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 component name that is variable sized. The a column with component name that is variable sized. The
skipping to change at page 114, line 35 skipping to change at page 114, line 35
be 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
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v) V = valueof(v)
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v) V = valueof(v)
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v) V = valueof(v)
index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA-TLV, L = 4+strlen(namev),
V = valueof(v) V = valueof(v)
. .
. .
. .
13. Multiple atomic operations. 13. Multiple atomic operations.
Note 1: This emulates adding a new nexthop entry and then Note 1: This emulates adding a new nexthop entry and then
atomically updating the L3 entries pointing to an old NH to atomically updating the L3 entries pointing to an old NH to
point to a new one. The assumption is both tables are in the point to a new one. The assumption is both tables are in the
same LFB same LFB
Note2: Observe the two operations on the LFB instance, both Note2: Observe the two operations on the LFB instance, both
are SET operations. are SET operations.
//Operation 1: Add a new entry to table2 index #20. //Operation 1: Add a new entry to table2 index #20.
OPER = SET-TLV OPER = SET-TLV
Path-TLV: Path-TLV:
flags = 0, IDCount = 2, IDs=4.20 flags = 0, IDCount = 2, IDs=4.20
FULLDATA TLV, V= valueof(j1),valueof(j2) FULLDATA-TLV, V= valueof(j1),valueof(j2)
// Operation 2: Update table1 entry which // Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20 // was pointing with t2 = 10 to now point to 20
OPER = SET-TLV OPER = SET-TLV
Path-data-TLV: Path-data-TLV:
flags = F_SELKEY, IDCount = 1, IDs=3 flags = F_SELKEY, IDCount = 1, IDs=3
KEYINFO = KeyID=1 KEY_DATA=10 KEYINFO-TLV = KeyID=1 KEY_DATA=10
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 1, IDs=2 flags = 0 IDCount = 1, IDs=2
FULLDATA TLV, V= 20 FULLDATA-TLV, V= 20
Result: Result:
//first operation, SET //first operation, SET
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 3, IDs=4.20 flags = 0 IDCount = 3, IDs=4.20
RESULT-TLV code = success RESULT-TLV code = success
FULLDATA TLV, V = valueof(j1),valueof(j2) FULLDATA-TLV, V = valueof(j1),valueof(j2)
// second operation SET - assuming entry 16 was updated // second operation SET - assuming entry 16 was updated
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data TLV Path-data TLV
flags = 0 IDCount = 2, IDs=3.16 flags = 0 IDCount = 2, IDs=3.16
Path-Data TLV Path-Data TLV
flags = 0 IDCount = 1, IDs = 2 flags = 0 IDCount = 1, IDs = 2
SET-RESULT-TLV code = success RESULT-TLV code = success
FULLDATA TLV, Length = XXXX v=20 FULLDATA-TLV, Length = XXXX v=20
14. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 14. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9.
Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is.
PER = SET-TLV PER = SET-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 6 flags = 0, IDCount = 1, IDs = 6
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA TLV, Length = XXXX, V = {100} FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
FULLDATA TLV, Length = XXXX, V = {200} FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
FULLDATA TLV, Length = XXXX, V = {300} FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA TLV, Length = XXXX, V = {100} FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
FULLDATA TLV, Length = XXXX, V = {200} FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
FULLDATA TLV, Length = XXXX, V = {300} FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA TLV, Length = XXXX, V = {100} FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
FULLDATA TLV, Length = XXXX, V = {200} FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
FULLDATA TLV, Length = XXXX, V = {300} FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 7 flags = 0, IDCount = 1, IDs = 7
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA TLV, Length = XXXX, V = {100} FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
FULLDATA TLV, Length = XXXX, V = {200} FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
FULLDATA TLV, Length = XXXX, V = {300} FULLDATA-TLV, Length = XXXX, V = {300}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 9 flags = 0, IDCount = 1, IDs = 9
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
FULLDATA TLV, Length = XXXX, V = {100} FULLDATA-TLV, Length = XXXX, V = {100}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
FULLDATA TLV, Length = XXXX, V = {200} FULLDATA-TLV, Length = XXXX, V = {200}
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
FULLDATA TLV, Length = XXXX, V = {300} FULLDATA-TLV, Length = XXXX, V = {300}
response: response:
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 6 flags = 0, IDCount = 1, IDs = 6
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
skipping to change at page 118, line 39 skipping to change at page 118, line 39
row with index 4, inside table5 entry 10 row with index 4, inside table5 entry 10
operation = GET-TLV operation = GET-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1 flags = 0 IDCount = 5, IDs=7.10.2.4.1
Results: Results:
operation = GET-RESPONSE-TLV operation = GET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1 flags = 0 IDCount = 5, IDs=7.10.2.4.1
FULLDATA TLV: L=XXXX, V = valueof(x1) FULLDATA-TLV: L=XXXX, V = valueof(x1)
16. From table5's row 10 table10, get X2s based on on the value of 16. From table5's row 10 table10, get X2s based on on the value of
x1 equaling 10 (recall x1 is KeyID 1) x1 equaling 10 (recall x1 is KeyID 1)
operation = GET-TLV operation = GET-TLV
Path-data-TLV Path-data-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2 flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO TLV, KeyID = 1, KEYDATA = 10 KEYINFO-TLV, KeyID = 1, KEYDATA = 10
Path-data TLV Path-data TLV
IDCount = 1, IDS = 2 //select x2 IDCount = 1, IDS = 2 //select x2
Results: Results:
If x1=10 was at entry 11: If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV operation = GET-RESPONSE-TLV
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
components are: components are:
p1, type u32, ID = 1 p1, type u32, ID = 1
p2, type array, ID = 2, array components of type type-A p2, type array, ID = 2, array components of type type-A
type-A: type-A:
skipping to change at page 120, line 12 skipping to change at page 120, line 12
a) using nesting a) using nesting
b) using a flat path data b) using a flat path data
A. Method using nesting A. Method using nesting
in one message with a single operation in one message with a single operation
operation = SET-TLV operation = SET-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10 flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV Path-data-TLV
flags = 0, IDCount = 1, IDs=1 flags = 0, IDCount = 1, IDs=1
FULLDATA TLV: L=XXXX, FULLDATA-TLV: L=XXXX,
V = {111} V = {111}
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20 flags = 0 IDCount = 2, IDs=2.20
Path-data-TLV Path-data-TLV
flags = 0, IDCount = 1, IDs=1 flags = 0, IDCount = 1, IDs=1
FULLDATA TLV: L=XXXX, FULLDATA-TLV: L=XXXX,
V = {222} V = {222}
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1 flags = 0, IDCount = 3, IDs=2.30.1
FULLDATA TLV: L=XXXX, FULLDATA-TLV: L=XXXX,
V = {333} V = {333}
Result: Result:
operation = SET-RESPONSE-TLV operation = SET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10 flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV Path-data-TLV
flags = 0, IDCount = 1, IDs=1 flags = 0, IDCount = 1, IDs=1
RESULT-TLV RESULT-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20 flags = 0 IDCount = 2, IDs=2.20
skipping to change at page 121, line 10 skipping to change at page 121, line 10
RESULT-TLV RESULT-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1 flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV RESULT-TLV
B. Method using a flat path data in B. Method using a flat path data in
one message with a single operation one message with a single operation
operation = SET-TLV operation = SET-TLV
Path-data TLV : Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1 flags = 0, IDCount = 3, IDs=6.10.1
FULLDATA TLV: L=XXXX, FULLDATA-TLV: L=XXXX,
V = {111} V = {111}
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
FULLDATA TLV: L=XXXX, FULLDATA-TLV: L=XXXX,
V = {222} V = {222}
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
FULLDATA TLV: L=XXXX, FULLDATA-TLV: L=XXXX,
V = {333} V = {333}
Result: Result:
operation = SET-TLV operation = SET-TLV
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 :
skipping to change at page 121, line 46 skipping to change at page 121, line 46
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:
operation = GET-RESPONSE-TLV operation = GET-RESPONSE-TLV
Path-data-TLV Path-data-TLV
flags = 0 IDCount = 0 flags = 0 IDCount = 0
FULLDATA encoding of the FE Object LFB FULLDATA-TLV encoding of the FE Object LFB
Authors' Addresses Authors' Addresses
Ligang Dong Ligang Dong
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
P.R.China P.R.China
Phone: +86-571-88071024 Phone: +86-571-88071024
 End of changes. 172 change blocks. 
330 lines changed or deleted 338 lines changed or added

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