draft-ietf-forces-protocol-10.txt   draft-ietf-forces-protocol-11.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: November 2, 2007 IBM Expires: January 9, 2008 IBM
J. Hadi Salim (Ed.) J. Hadi Salim (Ed.)
Znyx Znyx
H. Khosravi (Ed.) H. Khosravi (Ed.)
Intel Intel
W. M. Wang (Ed.) W. M. Wang (Ed.)
Zhejiang Gongshang University Zhejiang Gongshang University
July 8, 2007
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-10.txt draft-ietf-forces-protocol-11.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 39 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 November 2, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies the Forwarding and Control Element Separation This document specifies the Forwarding and Control Element Separation
(ForCES) protocol. ForCES protocol is used for communications (ForCES) protocol. ForCES protocol is used for communications
between Control Elements(CEs) and Forwarding Elements (FEs) in a between Control Elements(CEs) and Forwarding Elements (FEs) in a
skipping to change at page 3, line 18 skipping to change at page 3, line 18
co-editors, of this protocol specification, are: co-editors, of this protocol specification, are:
Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea
University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), University of Technology), Ram Gopal (Nokia), Robert Haas (IBM),
Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang
(Zhejiang Gongshang University). (Zhejiang Gongshang University).
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
1.1. Other Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12
4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15
4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16
4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17
4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 22 skipping to change at page 4, line 23
7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 56 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 56
7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 57 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 57
7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 60 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 60
7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 61 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 61
7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 64 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 64
7.4. Semantics of Message Direction . . . . . . . . . . . . . 64 7.4. Semantics of Message Direction . . . . . . . . . . . . . 64
7.5. Association Messages . . . . . . . . . . . . . . . . . . 65 7.5. Association Messages . . . . . . . . . . . . . . . . . . 65
7.5.1. Association Setup Message . . . . . . . . . . . . . . 65 7.5.1. Association Setup Message . . . . . . . . . . . . . . 65
7.5.2. Association Setup Response Message . . . . . . . . . 67 7.5.2. Association Setup Response Message . . . . . . . . . 67
7.5.3. Association Teardown Message . . . . . . . . . . . . 68 7.5.3. Association Teardown Message . . . . . . . . . . . . 68
7.6. Configuration Messages . . . . . . . . . . . . . . . . . 69 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 70
7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 69 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 70
7.6.2. Config Response Message . . . . . . . . . . . . . . . 71 7.6.2. Config Response Message . . . . . . . . . . . . . . . 72
7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 72 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 74
7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 72 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 74
7.7.2. Query Response Message . . . . . . . . . . . . . . . 73 7.7.2. Query Response Message . . . . . . . . . . . . . . . 76
7.8. Event Notification Message . . . . . . . . . . . . . . . 75 7.8. Event Notification Message . . . . . . . . . . . . . . . 78
7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 76 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 80
7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 78 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82
8. High Availability Support . . . . . . . . . . . . . . . . . . 80 8. High Availability Support . . . . . . . . . . . . . . . . . . 84
8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 80 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84
8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 83 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87
9. Security Considerations . . . . . . . . . . . . . . . . . . . 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 89
9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 85 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 89
9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 85 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 89
9.1.2. Message authentication . . . . . . . . . . . . . . . 86 9.1.2. Message authentication . . . . . . . . . . . . . . . 90
9.2. ForCES PL and TML security service . . . . . . . . . . . 86 9.2. ForCES PL and TML security service . . . . . . . . . . . 90
9.2.1. Endpoint authentication service . . . . . . . . . . . 86 9.2.1. Endpoint authentication service . . . . . . . . . . . 90
9.2.2. Message authentication service . . . . . . . . . . . 86 9.2.2. Message authentication service . . . . . . . . . . . 90
9.2.3. Confidentiality service . . . . . . . . . . . . . . . 86 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 90
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
11.1. Normative References . . . . . . . . . . . . . . . . . . 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 92
11.2. Informational References . . . . . . . . . . . . . . . . 88 11.2. Informational References . . . . . . . . . . . . . . . . 92
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 89 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 93
A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 89 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 93
A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 90 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 94
A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 91 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 95
A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 91 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 95
A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 91 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 95
A.6. Association Setup Response . . . . . . . . . . . . . . . 92 A.6. Association Setup Response . . . . . . . . . . . . . . . 96
A.7. Association Teardown Message . . . . . . . . . . . . . . 93 A.7. Association Teardown Message . . . . . . . . . . . . . . 97
Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 94 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 98
B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 99 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 103
B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 100 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 104
Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 101 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 105
Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 105 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 109
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124
Intellectual Property and Copyright Statements . . . . . . . . . 122 Intellectual Property and Copyright Statements . . . . . . . . . 126
1. Terminology and Conventions 1. Terminology and Conventions
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC2119 [RFC2119]. as described in BCP 14, RFC2119 [RFC2119].
1.1. Other Notation
In table Table 1 and table Table 2 the following notation is used to
indicate multiplicity:
(value)+ .... means "1 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
plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined
the ForCES requirements, and RFC 3746 has defined the ForCES the ForCES requirements, and RFC 3746 has defined the ForCES
framework. While there may be multiple protocols used within the framework. While there may be multiple protocols used within the
overall ForCES architecture, the term "ForCES protocol" and overall ForCES architecture, the term "ForCES protocol" and
"protocol" as used in this document refers to the protocol used to "protocol" as used in this document refers to the protocol used to
skipping to change at page 10, line 30 skipping to change at page 10, line 30
configuration entity that is operated on by the CE. Note that the configuration entity that is operated on by the CE. Note that the
LFB is a functionally accurate abstraction of the FE's processing LFB is a functionally accurate abstraction of the FE's processing
capabilities, but not a hardware-accurate representation of the FE capabilities, but not a hardware-accurate representation of the FE
implementation. implementation.
FE Topology - A representation of how the multiple FEs within a FE Topology - A representation of how the multiple FEs within a
single NE are interconnected. Sometimes this is called inter-FE single NE are interconnected. Sometimes this is called inter-FE
topology, to be distinguished from intra-FE topology (i.e., LFB topology, to be distinguished from intra-FE topology (i.e., LFB
topology). topology).
LFB (Logical Function Block) and LFB Instance - LFBs are categorized LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An
by LFB Classes. An LFB Instance represents an LFB Class (or Type) LFB Instance represents an LFB Class (or Type) existence. There may
existence. There may be multiple instances of the same LFB Class (or be multiple instances of the same LFB Class (or Type) in an FE. An
Type) in an FE. An LFB Class is represented by an LFB Class ID, and LFB Class is represented by an LFB Class ID, and an LFB Instance is
an LFB Instance is represented by an LFB Instance ID. As a result, represented by an LFB Instance ID. As a result, an LFB Class ID
an LFB Class ID associated with an LFB Instance ID uniquely specifies associated with an LFB Instance ID uniquely specifies an LFB
an LFB existence. existence.
LFB Metadata - Metadata is used to communicate per-packet state from LFB Metadata - Metadata is used to communicate per-packet state from
one LFB to another, but is not sent across the network. The FE model one LFB to another, but is not sent across the network. The FE model
defines how such metadata is identified, produced and consumed by the defines how such metadata is identified, produced and consumed by the
LFBs. It defines the functionality but not how metadata is encoded LFBs. It defines the functionality but not how metadata is encoded
within an implementation. within an implementation.
LFB Attribute - Operational parameters of the LFBs that must be LFB Attribute - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB visible to the CEs are conceptualized in the FE model as the LFB
attributes. The LFB attributes include, for example, flags, single attributes. The LFB attributes include, for example, flags, single
parameter arguments, complex arguments, and tables that the CE can parameter arguments, complex arguments, and tables that the CE can
read and/or write via the ForCES protocol (see below). read and/or write via the ForCES protocol (see below).
LFB Topology - Representation of how the LFB instances are logically LFB Topology - Representation of how the LFB instances are logically
interconnected and placed along the datapath within one FE. interconnected and placed along the datapath within one FE.
Sometimes it is also called intra-FE topology, to be distinguished Sometimes it is also called intra-FE topology, to be distinguished
from inter-FE topology. from inter-FE topology.
Pre-association Phase - The period of time during which an FE Manager Pre-association Phase - The period of time during which an FE Manager
(see below) and a CE Manager (see below) are determining which FE(s) and a CE Manager are determining which FE(s) and CE(s) should be part
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 point in the ForCES Framework in
[RFC3746]. This protocol does not apply to CE-to-CE communication, [RFC3746]. This protocol does not apply to CE-to-CE communication,
skipping to change at page 16, line 18 skipping to change at page 16, line 18
o complex parameters: send up to 4 association messages with o complex parameters: send up to 4 association messages with
increasing exponential timeout increasing exponential timeout
4.2. ForCES Protocol Phases 4.2. ForCES Protocol Phases
ForCES, in relation to NEs, involves two phases: the Pre-Association ForCES, in relation to NEs, involves two phases: the Pre-Association
phase, where configuration/initialization/bootup of the TML and PL phase, where configuration/initialization/bootup of the TML and PL
layer happens, and the association phase where the ForCES protocol layer happens, and the association phase where the ForCES protocol
operates to manipulate the parameters of the FEs. operates to manipulate the parameters of the FEs.
FE assoiated CE configures transition to UP FE associated CE configures transition to UP
+---->--->---+ +--->---->---->---->------->----+ +---->--->---+ +--->---->---->---->------->----+
| | | Y | | | Y
^ Y | | ^ Y | |
| | | Y | | | Y
+---+-------+ +------+--+ +--------+ +---+-------+ +------+--+ +--------+
|FE Pre- | | FE | | FE | |FE Pre- | | FE | | FE |
|Association| | DOWN | CE configures DOWN | UP | |Association| | DOWN | CE configures DOWN | UP |
|Phase | | State +<------<-----<------<-- + State | |Phase | | State +<------<-----<------<-- + State |
| | | | | | | | | | | |
+-----------+ +---------+ +--------+ +-----------+ +---------+ +--------+
skipping to change at page 16, line 41 skipping to change at page 16, line 41
+-<---<------<-----<------<----<---------<------+ +-<---<------<-----<------<----<---------<------+
FE loses association FE loses association
Figure 4: The FE State Machine Figure 4: The FE State Machine
In the mandated case, once associated, the FE can only be in one of In the mandated case, once associated, the FE can only be in one of
two states, as indicated above. When the FE is in the DOWN state, it two states, as indicated above. When the FE is in the DOWN state, it
is not forwarding packets. When the FE is in the UP state it may be is not forwarding packets. When the FE is in the UP state it may be
forwarding packets, depending on the configuration of its specific forwarding packets, depending on the configuration of its specific
LFBs. The FE MAY also be in other states when it is capable of LFBs. The FE MAY also be in other states when it is capable of
graceful restart and high availaibility. The extra transitions are graceful restart and high availability. The extra transitions are
explained in Section 8 and not discussed here so as to allow us to explained in Section 8 and not discussed here so as to allow us to
explain the basics with more clarity. explain the basics with more clarity.
The CE configures FE state transitions by means of the FE Object LFB, The CE configures FE state transitions by means of the FE Object LFB,
which is defined in [FE-MODEL] and also explained in Section 7.3.2. which is defined in [FE-MODEL] and also explained in Section 7.3.2.
In the FE Object LFB, FE state is defined as an attribute of the LFB, In the FE Object LFB, FE state is defined as an attribute of the LFB,
and CE configuration of the FE state equals CE configuration of this and CE configuration of the FE state equals CE configuration of this
attribute. Note that even in the FE DOWN state, the FE is attribute. Note that even in the FE DOWN state, the FE is
associated. associated.
skipping to change at page 23, line 19 skipping to change at page 23, line 19
MOT (Middle of Transaction) MOT (Middle of Transaction)
EOT (End of Transaction) EOT (End of Transaction)
ABT (Abort) ABT (Abort)
The COMMIT operation is used by the CE to signal to the FE(s) to The COMMIT operation is used by the CE to signal to the FE(s) to
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
commited 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 the TP flag is set
to Start of Transaction (SOT). Multi-part messages, after the first to Start of Transaction (SOT). Multi-part messages, after the first
one, are indicated by the Middle of Transaction flag (MOT). All one, are indicated by the Middle of Transaction flag (MOT). All
messages from the CE MUST set the AlwaysACK flag (Section 6) to messages from the CE MUST set the AlwaysACK flag (Section 6) to
solicit responses from the FE(s). 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 validates 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
commitment phase is signaled from the CE to the FE by an End of commitment phase is signaled from the CE to the FE by an End of
Transaction (EOT) configuration message with a COMMIT operation. Transaction (EOT) configuration message with a COMMIT operation.
skipping to change at page 24, line 38 skipping to change at page 24, line 38
them, may fail after the EOT response message has been sent by the FE them, may fail after the EOT response message has been sent by the FE
but before the CE has received all the responses, e.g. if the EOT but before the CE has received all the responses, e.g. if the EOT
response never reaches the CE. response never reaches the CE.
In this protocol revision, as indicated in Section 4.2.2.3, an FE In this protocol revision, as indicated in Section 4.2.2.3, an FE
losing an association would be required to get entirely new state losing an association would be required to get entirely new state
from the newly associated CE upon a re-association. Although this from the newly associated CE upon a re-association. Although this
approach is simplistic and provides likeliness of loosing datapath approach is simplistic and provides likeliness of loosing datapath
traffic, it is a design choice to avoid the additional complexity of traffic, it is a design choice to avoid the additional complexity of
managing graceful restarts. The HA mechanisms (Section 8) are managing graceful restarts. The HA mechanisms (Section 8) are
provided to allow for a continous operation in case of FE failures. provided to allow for a continuous operation in case of FE failures.
Flexibility is provided on how to react when an FE looses Flexibility is provided on how to react when an FE looses
association. This is dictated by the CE Failover policy (refer to association. This is dictated by the CE Failover policy (refer to
Section 8 and Section 7.3). Section 8 and Section 7.3).
4.3.1.2.4. Transaction Messaging Example 4.3.1.2.4. Transaction Messaging Example
This section illustrates an example of how a successful two phase This section illustrates an example of how a successful two phase
commit between a CE and an FE would look like in the simple case. commit between a CE and an FE would look like in the simple case.
skipping to change at page 29, line 43 skipping to change at page 29, line 43
|---------------------->| |---------------------->|
| | | |
Figure 8: Message exchange between CE and FE to establish an NE Figure 8: Message exchange between CE and FE to establish an NE
association association
On successful completion of this state, the FE joins the NE. On successful completion of this state, the FE joins the NE.
4.4.2. Association Established state or Steady State 4.4.2. Association Established state or Steady State
In this state, the FE is continously updated or queried. The FE may In this state, the FE is continuously updated or queried. The FE may
also send asynchronous event notifications to the CE, synchronous also send asynchronous event notifications to the CE, synchronous
heartbeat messages, or packet redirect message to the CE. This heartbeat messages, or packet redirect message to the CE. This
continues until a termination (or deactivation) is initiated by continues until a termination (or deactivation) is initiated by
either the CE or FE. Figure 9 below, helps illustrate this state. either the CE or FE. Figure 9 below, helps illustrate this state.
FE PL CE PL FE PL CE PL
| | | |
| Heart Beat | | Heart Beat |
|<---------------------------->| |<---------------------------->|
skipping to change at page 37, line 15 skipping to change at page 37, line 15
The ACK indicator flag is only used by the CE when sending a The ACK indicator flag is only used by the CE when sending a
Config Message (Section 7.6.1) or a HB message (Section 7.10) Config Message (Section 7.6.1) or a HB message (Section 7.10)
to indicate to the message receiver whether or not a response to indicate to the message receiver whether or not a response
is required by the sender. Note that for all other messages is required by the sender. Note that for all other messages
than the Config Message or the HB Message this flag MUST be than the Config Message or the HB Message this flag MUST be
ignored. ignored.
The flag values are defined as below: The flag values are defined as below:
'NoACK' (0b00) - to indicate that the message receiver 'NoACK' (0b00) - to indicate that the message receiver
MUST not to send any response message back to this MUST not send any response message back to this message
message sender. sender.
'SuccessACK'(0b01) - to indicate the message receiver 'SuccessACK'(0b01) - to indicate the message receiver
MUST send a response message back only when the message MUST send a response message back only when the message
has been successfully processed by the receiver. has been successfully processed by the receiver.
'FailureACK'(0b10) - to indicate the message receiver 'FailureACK'(0b10) - to indicate the message receiver
MUST send a response message back only when there is MUST send a response message back only when there is
failure by the receiver in processing (executing) the failure by the receiver in processing (executing) the
message. In other words, if the message can be processed message. In other words, if the message can be processed
successfully, the sender will not expect any response successfully, the sender will not expect any response
skipping to change at page 41, line 5 skipping to change at page 41, line 5
same Type of TLV. This is a design choice that was made to ease same Type of TLV. This is a design choice that was made to ease
debugging of the protocol. debugging of the protocol.
6.3. ILV 6.3. ILV
A slight variation of the TLV known as the ILV. This sets the type A slight variation of the TLV known as the ILV. This sets the type
("T") to be a 32-bit local index that refers to a ForCES element ID. ("T") to be a 32-bit local index that refers to a ForCES element ID.
(refer to Section 6.4.1). The Length part of the ILV is fixed at 32 (refer to Section 6.4.1). The Length part of the ILV is fixed at 32
bits. bits.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value | | Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: ILV Representation Figure 15: ILV Representation
skipping to change at page 41, line 26 skipping to change at page 41, line 28
It should be noted that the "I" values are of local scope and are It should be noted that the "I" values are of local scope and are
defined by the data declarations from the LFB definition. Refer to defined by the data declarations from the LFB definition. Refer to
Section 7.1.8 for discussions on usage of ILVs. Section 7.1.8 for discussions on usage of ILVs.
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 refered 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,
SPARSEDATA, and RESULT TLVs. SPARSEDATA, and RESULT TLVs.
6.4.1. Paths 6.4.1. Paths
The model draft [FE-MODEL] defines an XML-based language that allows The model draft [FE-MODEL] defines an XML-based language that allows
for a formal definition of LFBs. This is similar to the relationship for a formal definition of LFBs. This is similar to the relationship
between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB
and ASN.1 being analogous to the XML model language). Any entity and ASN.1 being analogous to the XML model language). Any entity
that the CE configures on an FE MUST be formally defined in an LFB. that the CE configures on an FE MUST be formally defined in an LFB.
These entities could be scalars (e.g., a 32-bit IPv4 address) or These entities could be scalars (e.g., a 32-bit IPv4 address) or
vectors (such as a nexthop table). Each entity within the LFB is vectors (such as a nexthop table). Each entity within the LFB is
given a numeric 32-bit identifier known as an "element id". This given a numeric 32-bit identifier known as an "element id". This
scheme allows the attribute to be "addressed" in a protocol scheme allows the attribute to be "addressed" in a protocol
construct. construct.
These addressable entities could be hierachical (e.g., a table column These addressable entities could be hierarchical (e.g., a table
or a cell within a table row). In order to address hierachical data, column or a cell within a table row). In order to address
the concept of a path is introduced by the model [FE-MODEL]. A path hierarchical data, the concept of a path is introduced by the model
is a series of 32-bit element IDs which are typically presented in a [FE-MODEL]. A path is a series of 32-bit element IDs which are
dot-notation (e.g., 1.2.3.4). Section (Section 7) formally defines typically presented in a dot-notation (e.g., 1.2.3.4). Section
how paths are used to reference data that is being encapsulated (Section 7) formally defines how paths are used to reference data
within a protocol message. that is being encapsulated within a protocol message.
6.4.2. Keys 6.4.2. Keys
The model draft [FE-MODEL] defines two ways to address table rows. The model draft [FE-MODEL] defines two ways to address table rows.
The standard/common mechanism is to allow table rows to be referenced The standard/common mechanism is to allow table rows to be referenced
by a 32-bit index. The secondary mechanism is via Keys which allow by a 32-bit index. The secondary mechanism is via Keys which allow
for content addressing. An example key is a multi-field content key for content addressing. An example key is a multi-field content key
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
skipping to change at page 44, line 18 skipping to change at page 44, line 18
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 Name | Top-Level | OPER-TLV(s) | Reference |
| | TLV | | | | | TLV | | |
+--------------+--------------+---------------------+---------------+ +--------------+--------------+---------------------+---------------+
| Association | LFBselect | REPORT | Section 7.5.2 | | Association | (LFBselect)* | REPORT | Section 7.5.2 |
| Setup | | | | | Setup | | | |
| | | | | | | | | |
| Association | LFBselect | none | Section 7.5.2 | | Association | ASRresult | none | Section 7.5.2 |
| Setup | | | | | Setup | | | |
| Response | | | | | Response | | | |
| | | | | | | | | |
| Association | LFBselect | none | Section 7.5.3 | | Association | ASTreason | none | Section 7.5.3 |
| Teardown | | | | | Teardown | | | |
| | | | | | | | | |
| Config | (LFBselect)+ | (SET | DEL | COMMIT | Section 7.6.1 | | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 |
| | | | TRCOMP | | | | | | DEL | COMMIT | | |
| | | SET-PROP)+ | | | | | TRCOMP)+ | |
| | | | | | | | | |
| Config | LFBselect | (SET-RESPONSE | | Section 7.6.2 | | Config | LFBselect | (SET-RESPONSE | | Section 7.6.2 |
| Response | | DEL-RESPONSE | | | | Response | | SET-PROP-RESPONSE | | |
| | | COMMIT-RESPONSE | | | | | | DEL-RESPONSE | | |
| | | SET-PROP-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 | | | | | Notification | | | |
| | | | | | | | | |
| Packet | LFBselect | REDIRECT | Section 7.9 | | Packet | REDIRECT-TLV | none | Section 7.9 |
| Redirect | | | | | Redirect | | | |
| | | | | | | | | |
| Heartbeat | LFBselect | 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 22 skipping to change at page 45, line 22
Each type of OPER-TLV is constrained as to how it describes the paths Each type of OPER-TLV is constrained as to how it describes the paths
and selectors of interest. The following BNF describes the basic and selectors of interest. The following BNF describes the basic
structure of an OPER-TLV and Table 2 gives the details for each type structure of an OPER-TLV and Table 2 gives the details for each type
OPER-TLV := 1*PATH-DATA-TLV OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA] PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR] PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV SELECTOR := KEYINFO-TLV
DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
1*PATH-DATA-TLV 1*PATH-DATA-TLV
KEYINFO-TLV := Keyid FULLDATA-TLV KEYINFO-TLV := KeyID FULLDATA-TLV
FULLDATA-TLV := encoded data element which may nest FULLDATA-TLV := encoded data element which may nest
further FULLDATA-TLVs further FULLDATA-TLVs
SPARSEDATA-TLV := encoded data that may have optionally SPARSEDATA-TLV := encoded data that may have optionally
appearing elements appearing elements
RESULT-TLV := Holds result code and optional FULLDATA-TLV RESULT-TLV := Holds result code and optional FULLDATA-TLV
Figure 17: BNF of OPER-TLV Figure 17: BNF of OPER-TLV
o PATH-DATA-TLV identifies the exact element targeted and may have o PATH-DATA-TLV identifies the exact element 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
skipping to change at page 46, line 21 skipping to change at page 46, line 21
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 and SPARSEDATA are
only allowed on SET or SET-PROP requests, or on responses which only allowed on SET or SET-PROP requests, or on responses which
return content information (GET-RESPONSE for example). PATH-DATA return content information (GET-RESPONSE for example). PATH-DATA
may be included to extend the path on any request. 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.
skipping to change at page 47, line 33 skipping to change at page 47, line 33
| GET | none | none | | GET | none | none |
| | | | | | | |
| GET-PROP | none | none | | GET-PROP | none | none |
| | | | | | | |
| GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| | | | | | | |
| GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* |
| | | | | | | |
| REPORT | (FULLDATA-TLV)+ | none | | REPORT | (FULLDATA-TLV)+ | none |
| | | | | | | |
| REDIRECT | none | none |
| | | |
| 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 contains the indication of whether the individual SET or
skipping to change at page 49, line 24 skipping to change at page 49, line 24
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 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 = LFBselect | Length | | Type = LFBselect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER-TLV | | OPER-TLV |
. . . .
skipping to change at page 51, line 13 skipping to change at page 51, line 13
operations. The different types are defined in Table 3, below. operations. The different types are defined in Table 3, below.
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| OPER-TLV | TLV | Comments | | OPER-TLV | TLV | Comments |
| | "Type" | | | | "Type" | |
+-------------------+--------+--------------------------------------+ +-------------------+--------+--------------------------------------+
| SET | 0x0001 | From CE to FE. Used to create or | | SET | 0x0001 | From CE to FE. Used to create or |
| | | add or update attributes | | | | add or update attributes |
| | | | | | | |
| SET-PROP | 0x0002 | From CE to FE. Used to create or | | SET-PROP | 0x0002 | From CE to FE. Used to create or |
| | | add or update attributes | | | | 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 43 skipping to change at page 52, line 43
A SET/SET-PROP operation on a variable length element with a length A SET/SET-PROP operation on a variable length element with a length
of 0 for the item is not the same as deleting it. If the CE wishes of 0 for the item is not the same as deleting it. If the CE wishes
to delete then the DEL operation should be used whether the path to delete then the DEL operation should be used whether the path
refers to an array element or an optional structure element. refers to an array element or an optional structure element.
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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RESULT | Length | | Type = RESULT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Reserved | | Result Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Result TLV Figure 19: Result TLV
Defined Result Values Defined Result Values
skipping to change at page 55, line 19 skipping to change at page 55, line 19
| | | that is unsupported by | | | | that is unsupported by |
| | | the message receiver. | | | | the message receiver. |
| | | | | | | |
| E_MEMORY_ERROR | 0x16 | A memory error occurred | | E_MEMORY_ERROR | 0x16 | A memory error occurred |
| | | while processing a | | | | while processing a |
| | | message (no error | | | | message (no error |
| | | detected in the message | | | | detected in the message |
| | | itself) | | | | itself) |
| | | | | | | |
| E_INTERNAL_ERROR | 0x17 | An unspecified error | | E_INTERNAL_ERROR | 0x17 | An unspecified error |
| | | occured while | | | | occurred while |
| | | processing a message | | | | processing a message |
| | | (no error detected in | | | | (no error detected in |
| | | the message itself) | | | | the message itself) |
| | | | | | | |
| - | 0x18-0xFE | Reserved | | - | 0x18-0xFE | Reserved |
| | | | | | | |
| 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) |
+-----------------------------+-----------+-------------------------+ +-----------------------------+-----------+-------------------------+
skipping to change at page 65, line 45 skipping to change at page 66, line 5
The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' The OPER-TLV in the LFBselect TLV is defined as a 'REPORT'
operation. More than one attribute may be announced in this operation. More than one attribute may be announced in this
message using REPORT operation to let the FE declare its message using REPORT operation to let the FE declare its
configuration parameters in an unsolicited manner. These may configuration parameters in an unsolicited manner. These may
contain attributes suggesting values such as the FE HB Interval, contain attributes suggesting values such as the FE HB Interval,
or the FEID. The OPER-TLV used is defined below. or the FEID. The OPER-TLV used is defined below.
OPER-TLV for Association Setup: OPER-TLV for Association Setup:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: OPER-TLV Figure 22: OPER-TLV
Type: Type:
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:
skipping to change at page 66, line 45 skipping to change at page 67, line 26
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
| |
| |
+-- LFBInstance = 0x1 +-- LFBInstance = 0x1
| |
+---OPER-TLV = REPORT +---OPER-TLV = REPORT
| |
+-- Path-data to one or more attributes +-- Path-data to one or more attributes
Figure 23: PDU Format For Association Setup Figure 23: PDU Format For Association Setup Message
7.5.2. Association Setup Response Message 7.5.2. Association Setup Response Message
This message is sent by the CE to the FE in response to the Setup This message is sent by the CE to the FE in response to the Setup
message. It indicates to the FE whether the setup is successful or message. It indicates to the FE whether the setup is successful or
not, i.e., whether an association is established. not, i.e., whether an association is established.
Message transfer direction: Message transfer direction:
CE to FE CE to FE
Message Header: Message Header:
The Message Type in the header is set MessageType= The Message Type in the header is set MessageType=
'AssociationSetupResponse'. The ACK flag in the header MUST be 'AssociationSetupResponse'. The ACK flag in the header MUST be
ignored, and the setup response message never expects to get any ignored, and the setup response message never expects to get any
more responses from the message receiver (FE). The destination more responses from the message receiver (FE). The destination
ID in the header will be set to the source ID in the ID in the header will be set to the source ID in the
corresponding association setup message, unless that source ID corresponding association setup message, unless that source ID
was 0. If the corresponding source ID was 0, then the CE will was 0. If the corresponding source ID was 0, then the CE will
assign an FE ID value and use that value for the destination ID. assign an FE ID value and use that value for the destination ID.
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 = ASRresult | Length | | Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Setup Result | | Association Setup Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: ASResult OPER-TLV Figure 24: ASResult OPER-TLV
Type (16 bits): Type (16 bits):
skipping to change at page 68, line 5 skipping to change at page 68, line 31
Association Setup Result (32 bits): Association Setup Result (32 bits):
This indicates whether the setup msg was successful or whether This indicates whether the setup msg was successful or whether
the FE request was rejected by the CE. the defined values are: the FE request was rejected by the CE. the defined values are:
0 = success 0 = success
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
format is shown below:
main hdr (type = Association Setup Response)
|
|
+--- T = ASResult
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)
Message Header: Message Header:
The Message Type in the header is set MessageType= The Message Type in the header is set MessageType=
"AssociationTeardown". The ACK flag MUST be ignored. The "AssociationTeardown". The ACK flag MUST be ignored. The
correlator field in the header MUST be set to zero and MUST be correlator field in the header MUST be set to zero and MUST be
ignored by the receiver. ignored by the receiver.
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 25: 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 5 skipping to change at page 69, line 42
1 - error - loss of heartbeats 1 - error - loss of heartbeats
2 - error - out of bandwidth 2 - error - out of bandwidth
3 - error - out of memory 3 - error - out of memory
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
format is shown below:
main hdr (type = Association Teardown)
|
|
+--- T = ASTreason
Figure 27: PDU Format for Association Teardown Message
7.6. Configuration Messages 7.6. Configuration Messages
The ForCES Configuration messages are used by CE to configure the FEs The ForCES Configuration messages are used by CE to configure the FEs
in a ForCES NE and report the results back to the CE. in a ForCES NE and report the results back to the CE.
7.6.1. Config Message 7.6.1. Config Message
This message is sent by the CE to the FE to configure LFB attributes This message is sent by the CE to the FE to configure LFB attributes
in the FE. This message is also used by the CE to subscribe/ in the FE. This message is also used by the CE to subscribe/
unsubscribe to LFB events. unsubscribe to LFB events.
skipping to change at page 69, line 31 skipping to change at page 70, line 31
CE to FE CE to FE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Config'. The The Message Type in the header is set MessageType= 'Config'. The
ACK flag in the header can be set to any value defined in ACK flag in the header can be set to any value defined in
Section 6.1, to indicate whether or not a response from FE is Section 6.1, to indicate whether or not a response from FE is
expected by the message. expected by the message.
OPER-TLV for Config: OPER-TLV for Config:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: OPER-TLV for Config Figure 28: OPER-TLV for Config
Type: Type:
The operation type for config message. two types of operations The operation type for config message. two types of operations
for the config message are defined: for the config message are defined:
Type = "SET" - this operation is to set LFB attributes Type = "SET" - this operation is to set LFB attributes
Type = "SET-PROP" - this operation is to set LFB attribute Type = "SET-PROP" - this operation is to set LFB attribute
properties properties
Type = "DEL" - this operation to delete some LFB Type = "DEL" - this operation to delete some LFB
attributes attributes
Type = "COMMIT" - this operation is sent to the FE to Type = "COMMIT" - this operation is sent to the FE to
commit in a 2pc transaction. A COMMIT TLV is an empty TLV commit in a 2pc transaction. A COMMIT TLV is an empty TLV
i.e it has no "V"alue. In other words, There is a Length i.e it has no "V"alue. In other words, There is a Length
of 4 (which is for the header only). of 4 (which is for the header only).
Type = "TRCOMP" - this operation is sent to the FE to mark Type = "TRCOMP" - this operation is sent to the FE to mark
the success from an NE perspective of a 2pc transaction. the success from an NE perspective of a 2pc transaction.
A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In
other words, There is a Length of 4 (which is for the other words, There is a Length of 4 (which is for the
header only). header only).
skipping to change at page 71, line 4 skipping to change at page 72, line 24
| |
| |
+-- 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 FULL or SPARSEDATA TLV(s)
| |
+-- T = operation { DEL } +-- T = operation { DEL }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
Figure 27: PDU Format for Config |
+-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV
.
.
Figure 29: PDU Format for Configuration Message
7.6.2. Config Response Message 7.6.2. Config Response Message
This message is sent by the FE to the CE in response to the Config This message is sent by the FE to the CE in response to the Config
message. It indicates whether the Config was successful or not on message. It indicates whether the Config was successful or not on
the FE and also gives a detailed response regarding the configuration the FE and also gives a detailed response regarding the configuration
result of each attribute. result of each attribute.
Message transfer direction: Message transfer direction:
FE to CE FE to CE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Config The Message Type in the header is set MessageType= 'Config
Response'. The ACK flag in the header is always ignored, and the Response'. The ACK flag in the header is always ignored, and the
Config Response message never expects to get any further response Config Response message never expects to get any further response
from the message receiver (CE). from the message receiver (CE).
OPER-TLV for Config Response: OPER-TLV for Config Response:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV | | PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: OPER-TLV for Config Response Figure 30: OPER-TLV for Config Response
Type: Type:
The operation type for Config Response message. Two types of The operation type for Config Response message. Two types of
operations for the Config Response message are defined: operations for the Config Response message are defined:
Type = "SET-RESPONSE" - this operation is for the response Type = "SET-RESPONSE" - this operation is for the response
of SET operation of LFB attributes of SET operation of LFB attributes
Type = "SET-PROP-RESPONSE" - this operation is for the Type = "SET-PROP-RESPONSE" - this operation is for the
response of SET-PROP operation of LFB attribute properties response of SET-PROP operation of LFB attribute properties
skipping to change at page 72, line 14 skipping to change at page 73, line 42
PATH-DATA-TLV: PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format that has been defined This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA BNF definition. The in section (Section 7) in the PATH-DATA BNF definition. The
restriction on the use of PATH-DATA-TLV for SET-RESPONSE restriction on the use of PATH-DATA-TLV for SET-RESPONSE
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
format is shown below:
main hdr (type = ConfigResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { SET-RESPONSE }
| |
| +-- // one or more path targets
| // associated with FULL or SPARSEDATA TLV(s)
|
+-- T = operation { DEL-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { COMMIT-RESPONSE }
| |
| +-- RESULT
Figure 31: PDU Format fpr Configuration Response message
7.7. Query Messages 7.7. Query Messages
The ForCES query messages are used by the CE to query LFBs in the FE The ForCES query messages are used by the CE to query LFBs in the FE
for informations like LFB attributes, capabilities, statistics, etc. for informations like LFB attributes, capabilities, statistics, etc.
Query Messages include the Query Message and the Query Response Query Messages include the Query Message and the Query Response
Message. Message.
7.7.1. Query Message 7.7.1. Query Message
A Query message is composed of a common header and a message body A Query message is composed of a common header and a message body
skipping to change at page 72, line 39 skipping to change at page 75, line 8
Message Header: Message Header:
The Message Type in the header is set to MessageType= 'Query'. The Message Type in the header is set to MessageType= 'Query'.
The ACK flag in the header is always ignored, and a full response The ACK flag in the header is always ignored, and a full response
for a query message is always expected. The Correlator field in for a query message is always expected. The Correlator field in
the header is set, so that the CE can locate the response back the header is set, so that the CE can locate the response back
from FE correctly. from FE correctly.
OPER-TLV for Query: OPER-TLV for Query:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET/GET-PROP | Length | | Type = GET/GET-PROP | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET/GET-PROP | | PATH-DATA-TLV for GET/GET-PROP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: TLV for Query Figure 32: TLV for Query
Type: Type:
The operation type for query. Two operation types are defined: The operation type for query. Two operation types are defined:
Type = "GET" - this operation is to request to get LFB Type = "GET" - this operation is to request to get LFB
attributes. attributes.
Type = "GET-PROP" - this operation is to request to get Type = "GET-PROP" - this operation is to request to get
LFB attributes. LFB attributes.
PATH-DATA-TLV for GET/GET-PROP: PATH-DATA-TLV for GET/GET-PROP:
skipping to change at page 73, line 43 skipping to change at page 76, line 25
| |
+-- T = operation { GET } +-- T = operation { GET }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| |
+-- T = operation { GET } +-- T = operation { GET }
. | . |
. +-- // one or more path targets . +-- // one or more path targets
. .
Figure 30: PDU Format Figure 33: PDU Format for Query Message
7.7.2. Query Response Message 7.7.2. Query Response Message
When receiving a Query message, the receiver should process the When receiving a Query message, the receiver should process the
message and come up with a query result. The receiver sends the message and come up with a query result. The receiver sends the
query result back to the message sender by use of the Query Response query result back to the message sender by use of the Query Response
Message. The query result can be the information being queried if Message. The query result can be the information being queried if
the query operation is successful, or can also be error codes if the the query operation is successful, or can also be error codes if the
query operation fails, indicating the reasons for the failure. query operation fails, indicating the reasons for the failure.
skipping to change at page 74, line 20 skipping to change at page 77, line 5
Message transfer direction: Message transfer direction:
from FE to CE from FE to CE
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set to MessageType=
'QueryResponse'. The ACK flag in the header is ignored. As a 'QueryResponse'. The ACK flag in the header is ignored. As a
response itself, the message does not expect a further response. response itself, the message does not expect a further response.
OPER-TLV for Query Response: OPER-TLV for Query Response:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: TLV for Query Response Figure 34: TLV for Query Response
Type: Type:
The operation type for query response. One operation type is The operation type for query response. One operation type is
defined: defined:
Type = "GET-RESPONSE" - this operation is to response to Type = "GET-RESPONSE" - this operation is to response to
get operation of LFB attributes. get operation of LFB attributes.
Type = "GET-PROP-RESPONSE" - this operation is to response Type = "GET-PROP-RESPONSE" - this operation is to response
to GET-PROP operation of LFB attributes. to GET-PROP operation of LFB attributes.
PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE:
This is generically a PATH-DATA-TLV format that has been defined This is generically a PATH-DATA-TLV format that has been defined
in section (Section 7) in the PATH-DATA BNF definition. The in section (Section 7) in the PATH-DATA BNF definition. The
PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA
TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The
RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and
FULLDATA TLVs are defined in Section 7.1.8. FULLDATA TLVs are defined in Section 7.1.8.
To better illustrate the above PDU format, a tree structure for the
format is shown below:
main hdr (type = QueryResponse)
|
|
+--- T = LFBselect
. |
. +-- LFBCLASSID = target LFB class
. |
|
+-- LFBInstance = target LFB instance
|
|
+-- T = operation { GET-RESPONSE }
| |
| +-- // one or more path targets
|
+-- T = operation { GET-PROP-RESPONSE }
. |
. +-- // one or more path targets
.
Figure 35: PDU Format for Query Response Message
7.8. Event Notification Message 7.8. Event Notification Message
Event Notification Message is used by FE to asynchronously notify CE Event Notification Message is used by FE to asynchronously notify CE
of events that happen in the FE. of events that happen in the FE.
All events that can be generated in an FE are subscribable by the CE. All events that can be generated in an FE are subscribable by the CE.
The CE can subscribe to an event via a Config message with SET-PROP The CE can subscribe to an event via a Config message with SET-PROP
operation, where the included path specifies the event, as defined by operation, where the included path specifies the event, as defined by
the LFB Library and described by the FE Model. the LFB Library and described by the FE Model.
skipping to change at page 75, line 30 skipping to change at page 79, line 7
FE to CE FE to CE
Message Header: Message Header:
The Message Type in the message header is set to The Message Type in the message header is set to
MessageType = 'EventNotification'. The ACK flag in the header MessageType = 'EventNotification'. The ACK flag in the header
MUST be ignored by the CE, and the event notification message does MUST be ignored by the CE, and the event notification message does
not expect any response from the receiver. not expect any response from the receiver.
OPER-TLV for Event Notification: OPER-TLV for Event Notification:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: TLV for Event Notification Figure 36: TLV for Event Notification
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
skipping to change at page 76, line 25 skipping to change at page 80, line 4
| |
| |
+-- T = operation { REPORT } +-- T = operation { REPORT }
| | | |
| +-- // one or more path targets | +-- // one or more path targets
| // associated with FULL/SPARSE DATA TLV(s) | // associated with FULL/SPARSE DATA TLV(s)
+-- T = operation { REPORT } +-- T = operation { REPORT }
. | . |
. +-- // one or more path targets . +-- // one or more path targets
. // associated with FULL/SPARSE DATA TLV(s) . // associated with FULL/SPARSE DATA TLV(s)
Figure 37: PDU Format for Event Notification Message
Figure 33: PDU Format
7.9. Packet Redirect Message 7.9. Packet Redirect Message
A packet Redirect message is used to transfer data packets between CE A packet Redirect message is used to transfer data packets between CE
and FE. Usually these data packets are control packets but they may and FE. Usually these data packets are control packets but they may
be just data-path packets which need further (exception or high- be just data-path packets which need further (exception or high-
touch) processing. It is also feasible that this message carries no touch) processing. It is also feasible that this message carries no
data packets and rather just metadata. data packets and rather just metadata.
The Packet Redirect message data format is formated as follows: The Packet Redirect message data format is formated as follows:
skipping to change at page 77, line 5 skipping to change at page 80, line 29
Message Header: Message Header:
The Message Type in the header is set to MessageType= The Message Type in the header is set to MessageType=
'PacketRedirect'. 'PacketRedirect'.
Message Body: Message Body:
This consists of one or more TLVs that contain or describe the This consists of one or more TLVs that contain or describe the
packet being redirected. The TLV is specifically a Redirect TLV packet being redirected. The TLV is specifically a Redirect TLV
(with the TLV Type="Redirect"). Detailed data format of a (with the TLV Type="Redirect"). Detailed data format of a
Redirect TLV for packet redirect message is as below: Redirect TLV for packet redirect message is as below:
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 = Redirect | Length | | Type = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV | | Meta Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV | | Redirect Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: 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 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: METADARA TLV Figure 39: METADARA 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value | | Meta Data Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: Meta Data ILV Figure 40: Meta Data ILV
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 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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data | | Redirected Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 37: 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
for all TLVs. The metadata infers what kind of packet is carried for all TLVs. The metadata infers what kind of packet is carried
in value field and therefore allows for easy decoding of data in value field and therefore allows for easy decoding of data
encapsulated encapsulated
To better illustrate the above PDU format, a tree structure for the
format is shown below:
main hdr (type = PacketRedirect)
|
|
+--- T = Redirect
. |
. +-- T = METADATA
| |
| +-- Meta Data ILV
| |
| +-- Meta Data ILV
| .
| .
|
+-- T = REDIRECTDATA
|
+-- // Redirected Data
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-
sensitive approach used. sensitive approach used.
A Heartbeat Message is sent by a ForCES element periodically. The A Heartbeat Message is sent by a ForCES element periodically. The
parameterization and policy definition for heartbeats for an FE is parameterization and policy definition for heartbeats for an FE is
managed as attributes of the FE Protocol Object LFB, and can be set managed as attributes of the FE Protocol Object LFB, and can be set
skipping to change at page 80, line 27 skipping to change at page 84, line 27
8.1. Relation with the FE Protocol 8.1. Relation with the FE Protocol
High Availability parameterization in an FE is driven by configuring High Availability parameterization in an FE is driven by configuring
the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1).
The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE
Heartbeat policy help in detecting connectivity problems between an Heartbeat policy help in detecting connectivity problems between an
FE and CE. The CE Failover policy defines the reaction on a detected FE and CE. The CE Failover policy defines the reaction on a detected
failure. failure.
Figure 38 extends the state machine illustrated in Figure 4 to allow Figure 43 extends the state machine illustrated in Figure 4 to allow
for new states that facilitate connection recovery. for new states that facilitate connection recovery.
+-----------------+ +-----------------+
Lost association && | Pre-Association | Lost association && | Pre-Association |
CE failover policy = 0 | (Association | CE failover policy = 0 | (Association |
+------------>-->--| in +<----+ +------------>-->--| in +<----+
| | progress) | | | | progress) | |
| +--------+--------+ | | +--------+--------+ |
| | | | | |
| Y | | Y |
skipping to change at page 81, line 51 skipping to change at page 85, line 51
| Resynchronize !CEFTI expired | | Resynchronize !CEFTI expired |
| complete && | | complete && |
| reconnected | | reconnected |
| +---------------+ | | +---------------+ |
| | Resynch state | | | | Resynch state | |
| | (via | | | | (via | |
+-----------| graceful |<--------+ +-----------| graceful |<--------+
| restart) | | restart) |
+---------------+ +---------------+
Figure 38: FE State Machine considering HA Figure 43: FE State Machine considering HA
Section 4.2 describes transitions between the UP, DOWN and Pre- Section 4.2 describes transitions between the UP, DOWN and Pre-
association states. In this section we deal with disconnected association states. In this section we deal with disconnected
states. states.
During a communication failure between the FE and CE (which is caused During a communication failure between the FE and CE (which is caused
due to CE or link reasons, i.e. not FE related), either the TML on due to CE or link reasons, i.e. not FE related), either the TML on
the FE will trigger the FE PL regarding this failure or it will be the FE will trigger the FE PL regarding this failure or it will be
detected using the HB messages between FEs and CEs. The detected using the HB messages between FEs and CEs. The
communication failure, regardless of how it is detected, MUST be communication failure, regardless of how it is detected, MUST be
considered as a loss of association between the CE and corresponding considered as a loss of association between the CE and corresponding
skipping to change at page 82, line 39 skipping to change at page 86, line 39
primary CE. If it fails to re-associate with any CE and the CEFTI primary CE. If it fails to re-associate with any CE and the CEFTI
expires, the FE transitions to the Pre-association state. expires, the FE transitions to the Pre-association state.
If the FE, while in the Disconnected state, manages to reconnect to a If the FE, while in the Disconnected state, manages to reconnect to a
new primary CE before CEFTI expires it transitions to the Resynch new primary CE before CEFTI expires it transitions to the Resynch
state. In the Resynch state, the FE tries to recover any state that state. In the Resynch state, the FE tries to recover any state that
may have been lost during the Disonnected state. Graceful restart is may have been lost during the Disonnected state. Graceful restart is
one such mechanism. How the FE achieves these goals is out of scope one such mechanism. How the FE achieves these goals is out of scope
for this document. for this document.
Figure 39 below illustrates the Forces message sequences that the FE Figure 44 below illustrates the Forces message sequences that the FE
uses to recover the connection. uses to recover the connection.
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| All msgs | | | All msgs | |
2 |<--------------------->| | 2 |<--------------------->| |
| | | | | |
skipping to change at page 83, line 25 skipping to change at page 87, line 25
| | | |
| Asso Estb,Caps exchange | | Asso Estb,Caps exchange |
3 |<------------------------------------------>| 3 |<------------------------------------------>|
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
4 |------------------------------------------->| 4 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
5 |<------------------------------------------>| 5 |<------------------------------------------>|
Figure 39: CE Failover for Report Primary Mode Figure 44: CE Failover for Report Primary Mode
A CE-to-CE synchronization protocol would be needed to support fast A CE-to-CE synchronization protocol would be needed to support fast
failover as well as to address some of the corner cases, however this failover as well as to address some of the corner cases, however this
will not be defined by the ForCES protocol as it is out of scope for will not be defined by the ForCES protocol as it is out of scope for
this specification. this specification.
An explicit message (a Config message setting Primary CE attribute in An explicit message (a Config message setting Primary CE attribute in
ForCES Protocol object) from the primary CE, can also be used to ForCES Protocol object) from the primary CE, can also be used to
change the Primary CE for an FE during normal protocol operation. change the Primary CE for an FE during normal protocol operation.
skipping to change at page 98, line 47 skipping to change at page 102, line 47
<attribute elementID="13" access="read-write"> <attribute elementID="13" access="read-write">
<name>LastCEID</name> <name>LastCEID</name>
<synopsis> <synopsis>
The Primary CE this FE was last associated with The Primary CE this FE was last associated with
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </attribute>
</attributes> </attributes>
<capabilities> <capabilities>
<capability elementID="30" access="read-only"> <capability elementID="30">
<name>SupportableVersions</name> <name>SupportableVersions</name>
<synopsis> <synopsis>
the table of ForCES versions that FE supports the table of ForCES versions that FE supports
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>u8</typeRef> <typeRef>u8</typeRef>
</array> </array>
</capability> </capability>
<capability elementID="31" access="read-only"> <capability elementID="31">
<name>HACapabilities</name> <name>HACapabilities</name>
<synopsis> <synopsis>
the table of HA capabilities the FE supports the table of HA capabilities the FE supports
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>FEHACapab</typeRef> <typeRef>FEHACapab</typeRef>
</array> </array>
</capability> </capability>
</capabilities> </capabilities>
skipping to change at page 111, line 35 skipping to change at page 115, line 35
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.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = F_SELKEY IDCount = 1, IDs=6 flags = F_SELKEY IDCount = 1, IDs=6
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 table 2. Note
that the j1,j2 pair are a defined key for the table 2. that the j1,j2 pair are a defined key for the table 2.
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 element name that is variable sized. The purpose a column with element name that is variable sized. The purpose
skipping to change at page 113, line 26 skipping to change at page 117, line 26
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 = 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
skipping to change at page 117, line 7 skipping to change at page 121, line 7
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
 End of changes. 79 change blocks. 
112 lines changed or deleted 250 lines changed or added

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