draft-ietf-forces-protocol-04.txt   draft-ietf-forces-protocol-05.txt 
Network Working Group A. Doria (editor) Network Working Group A. Doria (Ed.)
Internet-Draft ETRI Internet-Draft ETRI
Expires: January 19, 2006 July 18, 2005 Expires: April 26, 2006 R. Haas (Ed.)
IBM
J. Hadi Salim (Ed.)
Znyx
H. Khosravi (Ed.)
Intel
W. M. Wang (Ed.)
Zhejiang Gongshang University
October 23, 2005
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-04.txt draft-ietf-forces-protocol-05.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 33 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006. This Internet-Draft will expire on April 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This specification documents the Forwarding and Control Element This document specifies the Forwarding and Control Element Separation
Separation protocol. This protocol is designed to be used between a (ForCES) protocol. ForCES protocol is a message exchange protocol
Control Element and a Forwarding Element in a Routing Network that is used for communications between Control Elements(CEs) and
Element. Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE).
This specification is intended to meet the ForCES protocol
requirements defined in RFC3654. Besides the ForCES protocol
messages, the specification also defines the framework, the
mechanisms, and the Transport Mapping Layer (TML) requirements for
ForCES protocol.
Authors Authors
The participants in the ForCES Protocol Team, co-authors and co- The participants in the ForCES Protocol Team, co-authors and co-
editors, of this draft, are: editors, of this draft, are:
Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram
Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M
Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Sections of this document . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 9
3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . 8 3.1.1. The PL layer . . . . . . . . . . . . . . . . . . . . 11
3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . 10 3.1.2. The TML layer . . . . . . . . . . . . . . . . . . . . 12
3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . 11 3.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 12
3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . 11 3.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 13
3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . 12 3.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 14
3.2.1 Pre-association . . . . . . . . . . . . . . . . . . 12 3.2.2. Post-association . . . . . . . . . . . . . . . . . . 15
3.2.2 Post-association . . . . . . . . . . . . . . . . . . 13 3.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 17
3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . 14 3.3.1. Transactions, Atomicity, Execution and Responses . . 17
3.3.1 Transactions, Atomicity, Execution and Responses . . 14 3.3.2. Heartbeating Mechanism . . . . . . . . . . . . . . . 20
3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . 17 3.3.3. FE Object and FE protocol LFBs . . . . . . . . . . . 20
3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . 18 3.3.4. Scaling by Concurrency . . . . . . . . . . . . . . . 20
4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 19 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 22
4.1 TML Parameterization . . . . . . . . . . . . . . . . . . 20 4.1. TML Parameterization . . . . . . . . . . . . . . . . . . 23
5. Message encapsulation . . . . . . . . . . . . . . . . . . . 21 5. Message encapsulation . . . . . . . . . . . . . . . . . . . . 24
5.1 Common Header . . . . . . . . . . . . . . . . . . . . . 21 5.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Type Length Value . . . . . . . . . . . . . . . . . . . 24 5.2. Type Length Value(TLV) Structuring . . . . . . . . . . . 28
5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . 25 5.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 29
5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . 25 5.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 29
6. Protocol Construction . . . . . . . . . . . . . . . . . . . 26 5.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . 26 6. Protocol Construction . . . . . . . . . . . . . . . . . . . . 31
6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . 26 6.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 31
6.1.2 Protocol Visualization . . . . . . . . . . . . . . . 30 6.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 31
6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 33 6.1.2. Protocol Visualization . . . . . . . . . . . . . . . 39
6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . 34 6.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 42
6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . 35 6.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 43
6.3 Semantics of message Direction . . . . . . . . . . . . . 36 6.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 46
6.4 Association Messages . . . . . . . . . . . . . . . . . . 36 6.3. Semantics of message Direction . . . . . . . . . . . . . 46
6.4.1 Association Setup Message . . . . . . . . . . . . . 36 6.4. Association Messages . . . . . . . . . . . . . . . . . . 46
6.4.2 Association Setup Response Message . . . . . . . . . 39 6.4.1. Association Setup Message . . . . . . . . . . . . . . 46
6.4.3 Association Teardown Message . . . . . . . . . . . . 41 6.4.2. Association Setup Response Message . . . . . . . . . 48
6.5 Configuration Messages . . . . . . . . . . . . . . . . . 42 6.4.3. Association Teardown Message . . . . . . . . . . . . 49
6.5.1 Config Message . . . . . . . . . . . . . . . . . . . 42 6.5. Configuration Messages . . . . . . . . . . . . . . . . . 50
6.5.2 Config Response Message . . . . . . . . . . . . . . 45 6.5.1. Config Message . . . . . . . . . . . . . . . . . . . 50
6.6 Query and Query Response Messages . . . . . . . . . . . 47 6.5.2. Config Response Message . . . . . . . . . . . . . . . 52
6.6.1 Query Message . . . . . . . . . . . . . . . . . . . 47 6.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 53
6.6.2 Query Response Message . . . . . . . . . . . . . . . 49 6.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 53
6.7 Event Notification and Response Messages . . . . . . . . 50 6.6.2. Query Response Message . . . . . . . . . . . . . . . 55
6.7.1 Event Notification Message . . . . . . . . . . . . . 51 6.7. Event Notification Message . . . . . . . . . . . . . . . 56
6.7.2 Event Notification Response Message . . . . . . . . 53 6.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 58
6.8 Packet Redirect Message . . . . . . . . . . . . . . . . 54 6.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 61
6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . 57 6.10. Operation Summary . . . . . . . . . . . . . . . . . . . . 62
6.10 Operation Summary . . . . . . . . . . . . . . . . . . . 58 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 64
7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 60 7.1. Association Setup state . . . . . . . . . . . . . . . . . 64
7.1 Association Setup state . . . . . . . . . . . . . . . . 60 7.2. Association Established state or Steady State . . . . . . 65
7.2 Association Established state or Steady State . . . . . 61 8. High Availability Support . . . . . . . . . . . . . . . . . . 68
8. High Availability Support . . . . . . . . . . . . . . . . . 64 8.1. Responsibilities for HA . . . . . . . . . . . . . . . . . 70
8.1 Responsibilities for HA . . . . . . . . . . . . . . . . 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 71
9. Security Considerations . . . . . . . . . . . . . . . . . . 68 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 71
9.1 No Security . . . . . . . . . . . . . . . . . . . . . . 68 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 71
9.1.1 Endpoint Authentication . . . . . . . . . . . . . . 68 9.1.2. Message authentication . . . . . . . . . . . . . . . 72
9.1.2 Message authentication . . . . . . . . . . . . . . . 69 9.2. ForCES PL and TML security service . . . . . . . . . . . 72
9.2 ForCES PL and TML security service . . . . . . . . . . . 69 9.2.1. Endpoint authentication service . . . . . . . . . . . 72
9.2.1 Endpoint authentication service . . . . . . . . . . 69 9.2.2. Message authentication service . . . . . . . . . . . 72
9.2.2 Message authentication service . . . . . . . . . . . 69 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 73
9.2.3 Confidentiality service . . . . . . . . . . . . . . 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
11. References . . . . . . . . . . . . . . . . . . . . . . . . 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 75
11.1 Normative References . . . . . . . . . . . . . . . . . . 72 11.2. Informational References . . . . . . . . . . . . . . . . 75
11.2 Informational References . . . . . . . . . . . . . . . . 72 Appendix A. Authors' Addresses . . . . . . . . . . . . . . . . . 76
Author's Address . . . . . . . . . . . . . . . . . . . . . . 72 Appendix B. IANA Considerations . . . . . . . . . . . . . . . . 78
A. Individual Authors/Editors Contact . . . . . . . . . . . . . 73 B.1. Message Type Name Space . . . . . . . . . . . . . . . . . 78
B. IANA considerations . . . . . . . . . . . . . . . . . . . . 75 B.2. Operation Type . . . . . . . . . . . . . . . . . . . . . 79
C. Forces Protocol LFB schema . . . . . . . . . . . . . . . . . 76 B.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 79
C.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . 77 B.4. LFB Class Id Name Space . . . . . . . . . . . . . . . . . 79
C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . 77 B.5. Association Setup Repsonse . . . . . . . . . . . . . . . 80
C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . 77 B.6. Association Teardown Message . . . . . . . . . . . . . . 80
C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . 77 B.7. Configuration Request Result . . . . . . . . . . . . . . 81
C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . 78 Appendix C. Forces Protocol LFB schema . . . . . . . . . . . . . 82
C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . 78 C.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 86
D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 79 C.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 86
E. Implementation Notes . . . . . . . . . . . . . . . . . . . . 95 Appendix D. Data Encoding Examples . . . . . . . . . . . . . . . 87
E.1 TML considerations . . . . . . . . . . . . . . . . . . . 95 Appendix E. Use Cases . . . . . . . . . . . . . . . . . . . . . 91
E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . 95 Appendix F. changes between -03, -04, and -05 . . . . . . . . . 107
E.1.2 Message type inference to Mapping at the TML . . . . 96 Appendix G. changes between -02 and -03 . . . . . . . . . . . . 111
F. changes between -03 and -04 . . . . . . . . . . . . . . . . 98 Appendix H. Changes between -01 and -02 . . . . . . . . . . . . 112
G. changes between -02 and -03 . . . . . . . . . . . . . . . . 100 Appendix I. Changes between -00 and -01 . . . . . . . . . . . . 113
H. Changes between -01 and -02 . . . . . . . . . . . . . . . . 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
I. Changes between -00 and -01 . . . . . . . . . . . . . . . . 102 Intellectual Property and Copyright Statements . . . . . . . . . 116
Intellectual Property and Copyright Statements . . . . . . . 103
1. Introduction 1. Introduction
This specification provides a draft definition of an IP-based Forwarding and Control Element Separation (ForCES) aims to define an
protocol for Control Element control of an Forwarding Element. The architectural framework and associated protocols to standardize
protocol is a TLV based protocol that include commands for transport information exchange between the control plane and the forwarding
of LFB information as well as TLVs for association, configuration, plane in an ForCES Network Element (ForCES NE). RFC 3654 has defined
status, and events. the ForCES requirements, and RFC 3764 has defined the ForCES
framework. While there may be multiple protocols used within the
overall ForCES architecture, the term "ForCES protocol" refers only
to the protocol used to standardize the information exchange between
Control Elements(CEs) and Forwarding Elements(FEs) only. ForCES FE
model [FE-MODEL] represents the capabilities, state and configuration
of FEs within the context of the ForCES protocol, so that CEs can
accordingly control the FEs in a standardizded way and by means of
the ForCES protocol.
This specification does not specify a transport mechanism for This document defines the ForCES protocol specifications. The ForCES
messages, but does include a discussion of the services that must be protocol works in a master-slave mode in which FEs are slaves and CEs
provided by the transport interface. are masters. Information exchanged between FEs and CEs makes
extensive use of TLVs. The protocol includes commands for transport
of LFB configuration information as well as for association, status,
and event notifications, etc.
1.1 Sections of this document This specification does not define a transport mechanism for protocol
messages, but does include a discussion of service primitives that
must be provided by the underlying transport interface.
Section 2 provides a glossary of terminology used in the Section 2 provides a glossary of terminology used in the
specification. specification.
Section 3 provides an overview of the protocol including a discussion Section 3 provides an overview of the protocol including a discussion
on the protocol framework, descriptions of the protocol layer (PL) on the protocol framework, descriptions of the Protocol Layer (PL)
and a transport mapping layer (TML), as well as of the ForCES and a Transport Mapping Layer (TML), as well as of the ForCES
protocol mechanisms. protocol mechanisms.
While this document does not define the TML, Section 4 details the While this document does not define the TML, Section 4 details the
services that the TML must provide. services that a TML must provide (TML requirements).
The Forces protocol is defined to have a common header for all other The ForCES protocol is defined to have a common header for all
message types. The header is defined in Section 5.1, while the protocol messages. The header is defined in Section 5.1, while the
protocol messages are defined in Section 6. protocol messages are defined in Section 6.
Section 7 describes several Protocol Scenarios and includes message Section 7 describes several Protocol Scenarios and includes message
exchange descriptions. exchange descriptions.
Section 8 describes mechanism in the protocol to support high Section 8 describes mechanism in the protocol to support high
availability mechanisms including redundancy and fail over. availability mechanisms including redundancy and fail over.
Section 9 defines the security mechanisms provided by the PL and TML. Section 9 defines the security mechanisms provided by the PL and TML.
2. Definitions 2. Definitions
This document follows the terminology defined by the ForCES This document follows the terminology defined by the ForCES
Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. Requirements in [RFC3654] and by the ForCES framework in [RFC3746].
This document also uses the terminology defined by ForCES FE model in This document also uses the terminology defined by ForCES FE model in
[FE-MODEL]. We copy the definitions of some of the terminology as [FE-MODEL] repeated below for clarity.
indicated below:
Addressable Entity (AE) - A physical device that is directly Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on IP addressable given some interconnect technology. For example, on IP
networks, it is a device to which we can communicate using an IP networks, it is a device to which we can communicate using an IP
address; and on a switch fabric, it is a device to which we can address; and on a switch fabric, it is a device to which we can
communicate using a switch fabric port number. communicate using a switch fabric port number.
Forwarding Element (FE) - A logical entity that implements the ForCES Forwarding Element (FE) - A logical entity that implements the ForCES
protocol. FEs use the underlying hardware to provide per-packet protocol. FEs use the underlying hardware to provide per-packet
processing and handling as directed/controlled by a CE via the ForCES processing and handling as directed/controlled by a CE via the ForCES
skipping to change at page 5, line 38 skipping to change at page 6, line 37
Pre-association Phase - The period of time during which a FE Manager Pre-association Phase - The period of time during which a FE Manager
(see below) and a CE Manager (see below) are determining which FE and (see below) and a CE Manager (see below) are determining which FE and
CE should be part of the same network element. CE should be part of the same network element.
Post-association Phase - The period of time during which a FE does Post-association Phase - The period of time during which a FE does
know which CE is to control it and vice versa, including the time know which CE is to control it and vice versa, including 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.
FE Model - A model that describes the logical processing functions FE Model - A model that describes the logical processing functions of
of a FE. a FE.
FE Manager (FEM) - A logical entity that operates in the pre- FE Manager (FEM) - A logical entity that operates in the pre-
association phase and is responsible for determining to which CE(s) a association phase and is responsible for determining to which CE(s) a
FE should communicate. This process is called CE discovery and may FE should communicate. This process is called CE discovery and may
involve the FE manager learning the capabilities of available CEs. A involve the FE manager learning the capabilities of available CEs. A
FE manager may use anything from a static configuration to a pre- FE manager may use anything from a static configuration to a pre-
association phase protocol (see below) to determine which CE(s) to association phase protocol (see below) to determine which CE(s) to
use. Being a logical entity, a FE manager might be physically use. Being a logical entity, a FE manager might be physically
combined with any of the other logical entities such as FEs. combined with any of the other logical entities such as FEs.
skipping to change at page 6, line 24 skipping to change at page 7, line 23
High Touch Capability - This term will be used to apply to the High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents capabilities found in some forwarders to take action on the contents
or headers of a packet based on content other than what is found in or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT, the IP header. Examples of these capabilities include NAT-PT,
firewall, and L7 content recognition. firewall, and L7 content recognition.
Datapath -- A conceptual path taken by packets within the forwarding Datapath -- A conceptual path taken by packets within the forwarding
plane inside an FE. plane inside an FE.
LFB (Logical Function Block) type -- A template representing a fine- LFB (Logical Function Block) Class (or Type) -- the basic building
grained, logically separable and well-defined processing operating blocks that are operated on by the Forces protocol. The LFB is a
generally operating on packets in the datapath. LFB types are the well defined, logically separable functional block that resides in
basic building blocks of the FE model. the FE and is controlled by the CE via ForCES protocol. The LFB may
reside at the FE's datapath and process packets or may be purely a
control entity that is operated on by the CE.
LFB (Logical Function Block) Instance -- As a packet flows through an LFB (Logical Function Block) Instance -- As a packet flows through an
FE along a datapath, it flows through one or multiple LFB instances, FE along a datapath, it flows through one or multiple LFB instances,
with each implementing an instance of a certain LFB type. There may with each implementing an instance of a certain LFB type. There may
be multiple instances of the same LFB in an FE's datapath. Note that be multiple instances of the same LFB in an FE's datapath. Note that
we often refer to LFBs without distinguishing between LFB type and we often refer to LFBs without distinguishing between LFB type and
LFB instance when we believe the implied reference is obvious for the LFB instance when we believe the implied reference is obvious for the
given context. given context.
LFB Metadata -- Metadata is used to communicate per-packet state from LFB Metadata -- Metadata is used to communicate per-packet state from
skipping to change at page 7, line 19 skipping to change at page 8, line 20
Inter-FE Topology -- See FE Topology. Inter-FE Topology -- See FE Topology.
Intra-FE Topology -- See LFB Topology. Intra-FE Topology -- See LFB Topology.
Following terminologies are defined by this document: Following terminologies are defined by this document:
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" refers the overall ForCES architecture, the term "ForCES protocol" refers
only to the protocol used at the Fp reference point in the ForCES only to the protocol used at the Fp reference point in the ForCES
Framework in RFC3746 [RFC3746]. This protocol does not apply to CE- Framework in [RFC3746]. This protocol does not apply to CE-to-CE
to-CE communication, FE-to-FE communication, or to communication communication, FE-to-FE communication, or to communication between FE
between FE and CE managers. Basically, the ForCES protocol works in and CE managers. Basically, the ForCES protocol works in a master-
a master-slave mode in which FEs are slaves and CEs are masters. slave mode in which FEs are slaves and CEs are masters. This
This document defines the specifications for this ForCES protocol. document defines the specifications for this ForCES protocol.
ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol
architecture that defines the ForCES protocol messages, the protocol architecture that defines the ForCES protocol messages, the protocol
state transfer scheme, as well as the ForCES protocol architecture state transfer scheme, as well as the ForCES protocol architecture
itself (including requirements of ForCES TML (see below)). itself (including requirements of ForCES TML (see below)).
Specifications of ForCES PL are defined by this document. Specifications of ForCES PL are defined by this document.
ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in
ForCES protocol architecture that specifically addresses the protocol ForCES protocol architecture that specifically addresses the protocol
message transportation issues, such as how the protocol messages are message transportation issues, such as how the protocol messages are
mapped to different transport media (like TCP, IP, ATM, Ethernet, mapped to different transport media (like TCP, IP, ATM, Ethernet,
etc), and how to achieve and implement reliability, multicast, etc), and how to achieve and implement reliability, multicast,
ordering, etc. The ForCES TML is specifically addressed in a ordering, etc. The ForCES TML specifications are detailed in
separate ForCES TML Specification document. separate ForCES documents one for each TML.
3. Overview 3. Overview
The reader is referred to the Framework document [RFC3746], and in The reader is referred to the Framework document [RFC3746], and in
particular sections 3 and 4, for an architectural overview and an particular sections 3 and 4, for an architectural overview and an
explanation of how the ForCES protocol fits in. There may be some explanation of how the ForCES protocol fits in. There may be some
content overlap between the framework document and this section in content overlap between the framework document and this section in
order to provide clarity. order to provide clarity.
3.1 Protocol Framework 3.1. Protocol Framework
Figure 1 below is reproduced from the Framework document for clarity. Figure 1 below is reproduced from the Framework document for clarity.
It shows a NE with two CEs and two FEs. It shows a NE with two CEs and two FEs.
--------------------------------------- ---------------------------------------
| ForCES Network Element | | ForCES Network Element |
-------------- Fc | -------------- -------------- | -------------- Fc | -------------- -------------- |
| CE Manager |---------+-| CE 1 |------| CE 2 | | | CE Manager |---------+-| CE 1 |------| CE 2 | |
-------------- | | | Fr | | | -------------- | | | Fr | | |
| | -------------- -------------- | | | -------------- -------------- |
skipping to change at page 10, line 50 skipping to change at page 11, line 50
Both the PL and the TML layers are standardized by the IETF. While Both the PL and the TML layers are standardized by the IETF. While
only one PL layer is defined, different TMLs are expected to be only one PL layer is defined, different TMLs are expected to be
standardized. To interoperate the TML layer at the CE and FE are standardized. To interoperate the TML layer at the CE and FE are
expected to conform to the same definition. expected to conform to the same definition.
On transmit, the PL layer delivers its messages to the TML layer. On transmit, the PL layer delivers its messages to the TML layer.
The TML layer delivers the message to the destination TML layer(s). The TML layer delivers the message to the destination TML layer(s).
On receive, the TML delivers the message to its destination PL On receive, the TML delivers the message to its destination PL
layer(s). layer(s).
3.1.1 The PL layer 3.1.1. The PL layer
The PL is common to all implementations of ForCES and is standardized The PL is common to all implementations of ForCES and is standardized
by the IETF as defined in this document. The PL layer is responsible by the IETF as defined in this document. The PL layer is responsible
for associating an FE or CE to an NE. It is also responsible for for associating an FE or CE to an NE. It is also responsible for
tearing down such associations. An FE uses the PL layer to throw tearing down such associations. An FE uses the PL layer to throw
various subscribed-to events to the CE PL layer as well as respond to various subscribed-to events to the CE PL layer as well as respond to
various status requests issued from the CE PL. The CE configures various status requests issued from the CE PL. The CE configures
both the FE and associated LFBs attributes using the PL layer. In both the FE and associated LFB'ss operational parameters using the PL
addition the CE may send various requests to the FE to activate or layer. In addition the CE may send various requests to the FE to
deactivate it, reconfigure its HA parametrization, subscribe to activate or deactivate it, reconfigure its HA parameterization,
specific events etc. More details in Section 6. subscribe to specific events etc. More details in Section 6.
3.1.2 The TML layer 3.1.2. The TML layer
The TML layer is essentially responsible for transport of the PL The TML layer is essentially responsible for transport of the PL
layer messages. The TML is where the issues of how to achieve layer messages. The TML is where the issues of how to achieve
transport level reliability, congestion control, multicast, ordering, transport level reliability, congestion control, multicast, ordering,
etc are handled. It is expected more than one TML will be etc are handled. It is expected more than one TML will be
standardized. The different TMLs each could implement things standardized. The different TMLs each could implement things
differently based on capabilities of underlying media and transport. differently based on capabilities of underlying media and transport.
However, since each TML is standardized, interoperability is However, since each TML is standardized, interoperability is
guaranteed as long as both endpoints support the same TML. All guaranteed as long as both endpoints support the same TML. All
ForCES Protocol Layer implementations should be portable across all ForCES Protocol Layer implementations should be portable across all
TMLs, because all TMLs have the same top edge semantics as defined in TMLs, because all TMLs have the same top edge semantics as defined in
this document. this document.
3.1.3 The FEM/CEM Interface 3.1.3. The FEM/CEM Interface
The FEM and CEM components, although valuable in the setup and The FEM and CEM components, although valuable in the setup and
configurations of both the PL and TML layers, are out of scope of the configurations of both the PL and TML layers, are out of scope of the
ForCES protocol. The best way to think of them are as ForCES protocol. The best way to think of them are as
configurations/parameterizations for the PL and TML before they configurations/parameterizations for the PL and TML before they
become active (or even at runtime based on implementation). In the become active (or even at runtime based on implementation). In the
simplest case, the FE or CE read a static configuration file which simplest case, the FE or CE read a static configuration file. RFC
they use as the FEM/CEM interface. RFC 3746 has a lot more detailed 3746 has a lot more detailed descriptions on how the FEM and CEM
descriptions on how the FEM and CEM could be used. We discuss the could be used. We discuss the pre-association phase where the CEM
pre-association phase where the CEM and FEM play briefly in section and FEM play briefly in section Section 3.2.1.
Section 3.2.1.
An example of typical things FEM/CEM would configure would be TML An example of typical things FEM/CEM would configure would be TML
specific parameterizations such as: specific parameterizations such as:
a. how the TML connection should happen (example what IP addresses a. how the TML connection should happen (example what IP addresses
to use, transport modes etc); to use, transport modes etc);
b. the ID for the FE or CE would also be issued at this point. b. the ID for the FE or CE would also be issued at this point.
c. Security parameterization such as keys etc. c. Security parameterization such as keys etc.
skipping to change at page 12, line 6 skipping to change at page 13, line 4
specific parameterizations such as: specific parameterizations such as:
a. how the TML connection should happen (example what IP addresses a. how the TML connection should happen (example what IP addresses
to use, transport modes etc); to use, transport modes etc);
b. the ID for the FE or CE would also be issued at this point. b. the ID for the FE or CE would also be issued at this point.
c. Security parameterization such as keys etc. c. Security parameterization such as keys etc.
d. Connection association parameters d. Connection association parameters
Example "send up to 3 association messages each 1 second apart" Vs " Example "send up to 3 association messages each 1 second apart" Vs "
send up to 4 association messages with increasing exponential send up to 4 association messages with increasing exponential
timeout". timeout".
3.2 ForCES Protocol Phases 3.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. operates to manipulate the parameters of the FEs.
3.2.1 Pre-association start FEObject Admin up
-------+ +--->---->---->---->------->----+
| | Y
Y | |
| | Y
+------+--+ +--------+
| | | |
| DOWN | | UP |
| State | | State |
| | | |
+---------+ +--------+
^ Y
| |
+-<---<------<-----<------<----<---+
FEObject Admin Down/
Association lost
Figure 4: The FE State Machine
The FE can only be in one of 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 forwarding packets depending on the
configuration of its specific LFBs.
On start up the FE is in the DOWN state unless explicitly configured
by the CE to transition to the UP state. This MUST be done before
configuring any other LFBs that affect packet forwarding.
The FE transitions from the DOWN to the UP state when explicitly
configured to do so by the CE or when it looses its association with
the CE. It should be noted that what needs to be done for the FE to
properly complete the transition to the DOWN state is to stop packet
forwarding and that this may affect multiple LFBs. How this is
achieved is left as an implementation detail.
3.2.1. Pre-association
The ForCES interface is configured during the pre-association phase. The ForCES interface is configured during the pre-association phase.
In a simple setup, the configuration is static and is read from a In a simple setup, the configuration is static and is read from a
saved config file. All the parameters for the association phase are saved config file. All the parameters for the association phase are
well known after the pre-association phase is complete. A protocol well known after the pre-association phase is complete. A protocol
such as DHCP may be used to retrieve the config parameters instead of such as DHCP may be used to retrieve the config parameters instead of
reading them from a static config file. Note, this will still be reading them from a static config file. Note, this will still be
considered static pre-association. Dynamic configuration may also considered static pre-association. Dynamic configuration may also
happen using the Fc, Ff and Fl reference points. Vendors may use happen using the Fc, Ff and Fl reference points. Vendors may use
their own proprietary service discovery protocol to pass the their own proprietary service discovery protocol to pass the
parameters. parameters. Essentially only guidelines are provided here and the
details are left to the implementation.
The following are scenarios reproduced from the Framework Document The following are scenarios reproduced from the Framework Document to
to show a pre-association example. show a pre-association example.
<----Ff ref pt---> <--Fc ref pt-------> <----Ff ref pt---> <--Fc ref pt------->
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) (security exchange) (security exchange) (security exchange)
1|<------------>| authentication 1|<----------->|authentication 1|<------------>| authentication 1|<----------->|authentication
| | | | | | | |
(FE ID, attributes) (CE ID, attributes) (FE ID, attributes) (CE ID, attributes)
2|<-------------| request 2|<------------|request 2|<-------------| request 2|<------------|request
| | | | | | | |
3|------------->| response 3|------------>|response 3|------------->| response 3|------------>|response
(corresponding CE ID) (corresponding FE ID) (corresponding CE ID) (corresponding FE ID)
| | | | | | | |
| | | | | | | |
Figure 4: Examples of a message exchange over the Ff and Fc reference Figure 5: Examples of a message exchange over the Ff and Fc reference
points points
<-----------Fl ref pt--------------> | <-----------Fl ref pt--------------> |
FE Manager FE CE Manager CE FE Manager FE CE Manager CE
| | | | | | | |
| | | | | | | |
(security exchange) | | (security exchange) | |
1|<------------------------------>| | 1|<------------------------------>| |
| | | | | | | |
(a list of CEs and their attributes) | (a list of CEs and their attributes) |
2|<-------------------------------| | 2|<-------------------------------| |
| | | | | | | |
(a list of FEs and their attributes) | (a list of FEs and their attributes) |
3|------------------------------->| | 3|------------------------------->| |
| | | | | | | |
| | | | | | | |
Figure 5: An example of a message exchange over the Fl reference Figure 6: An example of a message exchange over the Fl reference
point point
Before the transition to the association phase, the FEM will have Before the transition to the association phase, the FEM will have
established contact with the appropriate CEM component. established contact with the appropriate CEM component.
Initialization of the ForCES interface will be completed, and Initialization of the ForCES interface will have completed, and
authentication as well as capability discovery may be complete as authentication as well as capability discovery may be complete. Both
well. Both the FE and CE would have the necessary information for the FE and CE would have the necessary information for connecting to
connecting to each other for configuration, accounting, each other for configuration, accounting, identification and
identification and authentication purposes. Both sides also would authentication purposes. To summarize, at the completion of this
have all the necessary protocol parameters such as timers, etc. The stage both sides have all the necessary protocol parameters such as
Fl reference point may continue to operate during the association timers, etc. The Fl reference point may continue to operate during
phase and may be used to force a disassociation of an FE or CE. the association phase and may be used to force a disassociation of an
Because the pre-association phase is out of scope, these details are FE or CE. Because the pre-association phase is out of scope, these
not discussed any further in this specification. The reader is details are not discussed any further in this specification. The
referred to the framework document [RFC3746] for more detailed reader is referred to the framework document [RFC3746] for a slightly
discussion. more detailed discussion.
3.2.2 Post-association 3.2.2. Post-association
In this phase, the FE and CE components communicate with each other In this phase, the FE and CE components communicate with each other
using the ForCES protocol (PL over TML) as defined in this document. using the ForCES protocol (PL over TML) as defined in this document.
There are three sub-phases: There are three sub-phases:
o Association setup state o Association Setup stage
o Established State o Established Stage
o Association teardown state. o Association Lost stage
3.2.2.1 Association setup state 3.2.2.1. Association Setup stage
The FE attempts to join the NE. The FE may be rejected or accepted. The FE attempts to join the NE. The FE may be rejected or accepted.
Once granted access into the NE, capabilities exchange happens with Once granted access into the NE, capabilities exchange happens with
the CE querying the FE. Once the CE has the FE capability the CE querying the FE. Once the CE has the FE capability
information, the CE can offer an initial configuration (possibly to information, the CE can offer an initial configuration (possibly to
restore state) and can query certain attributes within either an LFB restore state) and can query certain attributes within either an LFB
or the FE itself. or the FE itself.
More details are provided in the protocol scenarios section. More details are provided in the protocol scenarios section.
On successful completion of this state, the FE joins the NE and is On successful completion of this stage, the FE joins the NE and is
moved to the Established State. moved to the Established State.
3.2.2.2 Association Established state 3.2.2.2. Association Established stage
In this state the FE is continuously updated or queried. The FE may In this stage the FE is continuously updated or queried. The FE may
also send asynchronous event notifications to the CE or synchronous also send asynchronous event notifications to the CE or synchronous
heartbeat notifications. This continues until a termination is heartbeat notifications if programmed to do so. This continues until
initiated by either the CE or the FE. a termination occurs because of loss of connectivity or is initiated
by either the CE or the FE.
Refer to section on protocol scenarios Section 7 for more details. Refer to section on protocol scenarios Section 7 for more details.
3.3 Protocol Mechanisms 3.2.2.3. Association Lost stage
In this state, both or either the CE or FE declare the other side is
no longer associated. The disconnection could be physically
initiated by either party for administrative purposes but may also be
driven by operation reasons such as loss of connectivity.
It should be noted that loss of connectivity between TMLs is not
necessarily indictive of loss of association between respective PL
layers unless the programmed FE Protocol Object time limit is
exceeded. In other words if the TML repairs the transport loss
before then, the association would still be valid.
When an association is lost between a CE and FE, the FE continues to
operate as instructed by the CE via the CE failover policy (for
further discussion refer to Section 8 and Appendix C).
For this revision of the protocol (as defined in this document), the
FE, upon re-association, MUST declare all the state it has as invalid
and retrieve new state. This approach is motivated by a desire for
simplicity (as opposed to efficiency).
3.3. Protocol Mechanisms
Various semantics are exposed to the protocol users via the PL header Various semantics are exposed to the protocol users via the PL header
including: Transaction capabilities, atomicity of transactions, two including: Transaction capabilities, atomicity of transactions, two
phase commits, batching/parallelization, High Availability and phase commits, batching/parallelization, High Availability and
failover as well as command windows. failover as well as command windows.
3.3.1 Transactions, Atomicity, Execution and Responses 3.3.1. Transactions, Atomicity, Execution and Responses
In the master-slave relationship the CE instructs one or more FEs on In the master-slave relationship the CE instructs one or more FEs on
how to execute operations and how to report back the results. how to execute operations and how to report back the results.
This section details the different modes of execution that a CE can This section details the different modes of execution that a CE can
order the FE(s) to perform in Section 3.3.1.1. It also describes the order the FE(s) to perform in Section 3.3.1.1. It also describes the
different modes a CE can ask the FE(s) to format the responses back different modes a CE can ask the FE(s) to format the responses back
after processing the operations requested. after processing the operations requested.
3.3.1.1 Execution 3.3.1.1. Execution
There are 3 execution modes that could be requested for a batch of There are 3 execution modes that could be requested for a batch of
operations spanning on one or more LFB selectors: operations spanning on one or more LFB selectors:
a. Transactional execute-all-or-none a. Transactional execute-all-or-none
b. Loose transactional execute-until-failure b. Loose transactional execute-until-failure
c. Non-transactional continue-execute-on-failure c. Non-transactional continue-execute-on-failure
3.3.1.1.1 'all-or-none' Atomic transaction 3.3.1.1.1. 'all-or-none' Atomic transaction
A transaction maybe atomic: A transaction maybe atomic:
a. Within an FE alone a. Within an FE alone
Example: updating multiple tables which are dependent on each Example: updating multiple tables which are dependent on each
other. If updating one fails, then any others already updated other. If updating one fails, then any others already updated
must be undone. must be undone.
b. Across the NE b. Distributed across the NE
Example: updating the same type of table(s) that are Example: updating table(s) that are inter-dependent across
interdependent across several FEs (such as L3 forwarding related several FEs (such as L3 forwarding related tables).
tables).
3.3.1.1.2 Transaction Definition For distributed transactional consistency across FEs, a classical
transactional protocol known as Two Phase Commit [2PCREF] is
supported.
3.3.1.1.2. Transaction Definition
We define a transaction as a collection of one or more ForCES We define a transaction as a collection of one or more ForCES
operations within one or more PL messages that MUST meet the ACIDity operations within one or more PL messages that MUST meet the ACIDity
properties[ACID], defined as: properties[ACID], defined as:
o *Atomicity*. In a transaction involving two or more discrete o *Atomicity*. In a transaction involving two or more discrete
pieces of information, either all of the pieces are committed or pieces of information, either all of the pieces are committed or
none are. none are.
o *Consistency*. A transaction either creates a new and valid state o *Consistency*. A transaction either creates a new and valid state
skipping to change at page 15, line 48 skipping to change at page 18, line 27
o *Durability*. Committed data is saved by the system such that, o *Durability*. Committed data is saved by the system such that,
even in the event of a failure and system restart, the data is even in the event of a failure and system restart, the data is
available in its correct state. available in its correct state.
There are cases where the CE knows exact memory and implementation There are cases where the CE knows exact memory and implementation
details of the FE such as in the case of a FE-CE pair from the same details of the FE such as in the case of a FE-CE pair from the same
vendor where the FE-CE pair is tightly coupled. In such a case, the vendor where the FE-CE pair is tightly coupled. In such a case, the
transactional operations maybe simplified further by extra transactional operations maybe simplified further by extra
computation at the CE. We do not discuss this view further other computation at the CE. We do not discuss this view further other
than to mention it in not dissallowed. For the purpose of than to mention it is not dissallowed. For the purpose of
interopability, we define a classical transactional protocol known as interopability, we define a classical transactional protocol known as
two phase commit which meets the ACID properties to be used for two phase commit which meets the ACID properties to be used for
transactions. transactions.
3.3.1.1.3 Transaction protocol 3.3.1.1.3. Transaction protocol
A 2PC starts with a START | ATOMIC flag on its first message of a A 2PC [2PCREF] configuration message starts with the header flags
transaction. A transaction may span multiple messages. It is up to containg a SOT(start of transaction) and AT (Atomic Transaction) on
the CE to keep track of the different seq #s making up a transaction. its first message configuration message. A transaction may span
This may then be followed by more messages which are part of the same multiple messages. It is up to the CE to keep track of the different
atomic transaction. outstanding messages making up a transaction. As an example, one
could use the correlator field to mark transactions and a sequence
field to label the different messages within the same atomic
transaction.
Any failure notified by the FE causes the CE to execute an ABORT to Any failure notified by the FE causes the CE to execute an ABT (Abort
all FEs involved in the transaction, rolling back all previously Transaction) to all FEs involved in the transaction, rolling back all
executed operations in the transaction. previously executed operations in the transaction.
The transaction commitment phase is signalled by an empty DONE msg [Editorial Note: We need to discuss how to issue the ABORT - flags vs
type. type]
3.3.1.1.4 Recovery The transaction commitment phase is signalled from the CE to the FE
by an empty EOT configuration message.
The FE MUST respond to the CE's EOT message. If no response is
received from the CE within a specified timeout, the transaction MUST
be aborted by the CE.
3.3.1.1.4. Recovery
Any of the participating FEs, or the CE, or the associations between Any of the participating FEs, or the CE, or the associations between
them, may fail after the DONE message has left the CE and before it them, may fail after the EOT response message has left the FE and
has received all the responses, (possibly the DONE never reached the before it has received all the responses, (possibly the EOT response
FEs). At this point it is known that none of the operations failed never reached the CE).
but it is presumed that the data has not yet been made durable by the
FEs. The means of detecting such failures may include loss of
heartbeat (within the scope of ForCES) or mechanisms outside the
scope of ForCES. When the associations are re-established, the CE
will discover a transaction in an intermediate state. Some FEs will
have made the data durable and closed the transaction; others may
have failed while doing so, and may, or may not, still have that
data. At this point the transaction enters the recovery phase.
The CE re-issues an empty DONE message to all FEs involved in the In this protocol revision, for sake of simplicity as indicated in
transaction. Those that completed the transaction confirm this to Section 3.2.2.3, an FE losing an association would be required to get
the CE. Those that did not, commit the data and confirm this to the new state from the newly associated CE from scratch upon a
CE. An FE that has lost all records of the transaction MUST reply reassociation. The decision on what an FE should do after a lost
with status UNKNOWN and the actions subsequently taken by the CE are association is dictated by the CE Failover policy (refer to Section 8
implementation dependent. and Section 6.2).
3.3.1.1.5 continue-execute-on-failure 3.3.1.1.5. continue-execute-on-failure
In which several independent operations are targeted at one or more In which several independent operations are targeted at one or more
LFB selectors. Execution continues at the FE when one or more LFB selectors. Execution continues at the FE when one or more
operations fail. This mode is signalled by a missing ATOMIC flag. operations fail. This mode is signalled by a missing AT flag.
3.3.1.1.6 execute-until-falure 3.3.1.1.6. execute-until-failure
In which all operations are executed on FE sequentially until first In which all operations are executed on FE sequentially until first
failure. The rest of the operations are not executed but everything failure. The rest of the operations are not executed but everything
up to failed is not undone unlike the case of all-or-none execution. up to failed is not undone unlike the case of all-or-none execution.
flag: GOTON (global) Editorial note we need an extra main header flag to signal this .
EUF for lack of a better name.
3.3.1.1.7 Relation to Multipart messages 3.3.1.1.7. Relation to Multipart messages
Multipart flags apply. I.e all messages in a transaction except for Multipart messages after the first one are indicated by the MOT flag
the last have a MULTIPART flag on. (Middle of Transaction). The first message is indicated by SOT and
the last by EOT.
There has to be consistency across the multi parts of the messages. Multi-part messages MUST be consistent in their use of execution
In other words the first message starting with mode #1 above, implies modes. If the first message starts with one mode (such as continue-
the rest do. Any inconsitency implies a cancelled transaction in execute-on-failure mode), then it implies the rest that are part of
which all messages are dropped and the sender NACKED. the same multi-part messages do. Any inconsitency implies an error
and a cancelled transaction in which all messages are dropped and the
sender NACKED.
3.3.2 FE, CE, and FE protocol LFBs 3.3.2. Heartbeating Mechanism
All PL messages operate on LFB structures as this provides more Hearbeats between FEs and CEs are traffic sensitive. A HB is sent
only if no PL traffic is sent between the CE and FE within a
configured interval. This has the effect of reducing the amount of
HB traffic in the case of busy PL periods.
A HB can be sourced by either the CE or FE. When sourced by the CE,
a response can be requested (similar to the ICMP ping protocol). The
FE can only generate HBs in the case of being configured to do so by
the CE. Refer to Section 6.2.1 and Section 6.9 for details.
3.3.3. FE Object and FE protocol LFBs
All PL messages operate on LFB constructs as this provides more
flexibility for future enhancements. This means that maintenance and flexibility for future enhancements. This means that maintenance and
configurability of FEs, NE, as well as the ForCES protocol itself configurability of FEs, NE, as well as the ForCES protocol itself
must be expressed in terms of this LFB architecture. For this reason must be expressed in terms of this LFB architecture. For this reason
special LFBs are created to accomodate this need. special LFBs are created to accomodate this need.
In addition, this shows how the ForCES protocol itself can be In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc. control functions such as IP forwarding, filtering, etc.
To achieve this, the following LFBs are used: To achieve this, the following speacilized LFBs are introduced:
o FE Protocol LFB
o FE LFB
These LFBs are detailed in Section 6.2. A short description is o FE Protocol LFB which is used to control the ForCES protocol.
provided here:
o The FE Protocol LFB is a logical entity in each FE that is used to o FE Object LFB which is used to controls attributes relative to the
control the ForCES protocol. The CE operates on this LFB to FE itself. Such attributes include FEState (refer to model
subscribe or unsubscribe to Heartbeat messages, define the draft), vendor, etc.
Heartbeat interval, or to discover which ForCES protocol version
is supported and which TMLs the FE supports. The FE Protocol LFB
also contains the various ForCES ID to be used: unicast IDs a
table of the PL multicast IDs the FE must be listening to.
o The FE LFB (referred to as "FE attributes" in the model draft) These LFBs are detailed in Section 6.2.
should not be confused with the FE Protocol Object. The FE LFB is
a logical entity in each FE and contains attributes relative to
the FE itself, and not to the operation of the ForCES protocol
between the CE and the FE. Such attributes can be FEState (refer
to model draft), vendor, etc. The FE LFB contains in particular a
table that maps a virtual LFB Instance ID to one or more Instance
IDs of LFBs in the FE.
3.3.3 Scaling by Concurrency 3.3.4. Scaling by Concurrency
It is desirable that the PL layer not become the bottleneck when It is desirable that the PL layer not become the bottleneck when
larger bandwidth pipes become available. To pick a mythical example larger bandwidth pipes become available. To pick a mythical example
in today's terms, if a 100Gbps pipe is available and there is in today's terms, if a 100Gbps pipe is available and there is
sufficient work then the PL layer should be able to take advantage of sufficient work then the PL layer should be able to take advantage of
this and use all of the 100Gbps pipe. Two mechanisms are provided to this and use all of the 100Gbps pipe. Two mechanisms are provided to
achieve this. The first one is batching and the second one is a achieve this. The first one is batching and the second one is a
command window. command window.
Batching is the ability to send multiple commands (such as Config) in Batching is the ability to send multiple commands (such as Config) in
one PDU. The size of the batch will be affected by, amongst other one PDU. The size of the batch will be affected by, amongst other
things, the path MTU. The commands may be part of the same things, the path MTU. The commands may be part of the same
transaction or part of unrelated transactions that are independent of transaction or part of unrelated transactions that are independent of
each other. each other.
Command windowing allows for pipelining of independent transactions Command windowing allows for pipelining of independent transactions
which do not affect each other. Each independent transaction could which do not affect each other. Each independent transaction could
consist of one or more batches. consist of one or more batches.
3.3.3.1 Batching 3.3.4.1. Batching
There are several batching levels at different protocol hierarchies. There are several batching levels at different protocol hierarchies.
o multiple PL PDUs can be aggregated under one TML message o multiple PL PDUs can be aggregated under one TML message
o multiple LFB classes and instances can be addressed within one PL o multiple LFB classes and instances (as indicated in the LFB
PDU selector) can be addressed within one PL PDU
o Multiple operations can be addressed to a single LFB class and o Multiple operations can be addressed to a single LFB class and
instance instance
3.3.4.2. Command Pipelining
The protocol allows any number of messages to be issued by the CE
before the corresponding acknowledgments (if requested) have been
returned by the FE. Hence pipelining is inherently supported by the
protocol. Matching responses with requests messages can be done
using the correlator field in the message header.
4. TML Requirements 4. TML Requirements
The requirements below are expected to be delivered by the TML. This The requirements below are expected to be delivered by the TML. This
text does not define how such mechanisms are delivered. As an text does not define how such mechanisms are delivered. As an
example they could be defined to be delivered via hardware or between example they could be defined to be delivered via hardware or between
2 or more TML processes on different CEs or FEs in protocol level 2 or more TML processes on different CEs or FEs in protocol level
schemes. schemes.
Each TML must describe how it contributes to achieving the listed Each TML must describe how it contributes to achieving the listed
ForCES requirements. If for any reason a TML does not provide a ForCES requirements. If for any reason a TML does not provide a
skipping to change at page 19, line 32 skipping to change at page 22, line 32
should support the following security services and describe how should support the following security services and describe how
they are achieved. they are achieved.
* Endpoint authentication of FE and CE. * Endpoint authentication of FE and CE.
* Message Authentication * Message Authentication
* Confidentiality service * Confidentiality service
3. Congestion Control 3. Congestion Control
The congestion control scheme used needs to be defined. The congestion control scheme used needs to be defined. The
Additionally, the circumstances under which notification is sent congestion control mechanism defined by the TML should prevent
to the PL to notify it of congestion must be defined. the FE from being overloaded by the CE. Additionally, the
circumstances under which notification is sent to the PL to
notify it of congestion must be defined.
4. Uni/multi/broadcast addressing/delivery if any 4. Uni/multi/broadcast addressing/delivery if any
If there is any mapping between PL and TML level Uni/Multi/ If there is any mapping between PL and TML level Uni/Multi/
Broadcast addressing it needs to be defined. Broadcast addressing it needs to be defined.
5. HA decisions 5. HA decisions
It is expected that availability of transport links is the TML's It is expected that availability of transport links is the TML's
responsibility. However, on config basis, the PL layer may wish responsibility. However, on config basis, the PL layer may wish
to participate in link failover schemes and therefore the TML to participate in link failover schemes and therefore the TML
must support this capability. must support this capability.
Please refer to the HA Section Section 8 for details. Please refer to Section 8 for details.
6. Encapsulations used. 6. Encapsulations used.
Different types of TMLs will encapsulate the PL messages on Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the different types of headers. The TML needs to specify the
encapsulation used. encapsulation used.
7. Prioritization 7. Prioritization
It is expected that the TML will be able to handle up to 8 It is expected that the TML will be able to handle up to 8
priority levels needed by the PL layer and will provide priority levels needed by the PL layer and will provide
preferential treatment. preferential treatment.
skipping to change at page 20, line 21 skipping to change at page 23, line 21
8. The requirement for supporting up to 8 priority levels does not 8. The requirement for supporting up to 8 priority levels does not
mean that the underlying TML MUST be capable of handling up to 8 mean that the underlying TML MUST be capable of handling up to 8
priority levels. In such an event the priority levels should be priority levels. In such an event the priority levels should be
divided between the available TML priotity levels. For example, divided between the available TML priotity levels. For example,
if the TML only support 2 priority levels, the 0-3 could go in if the TML only support 2 priority levels, the 0-3 could go in
one TML priority level, while 4-7 could go in the other. one TML priority level, while 4-7 could go in the other.
9. Protection against DoS attacks 9. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6 As described in the Requirements RFC 3654, section 6
4.1 TML Parameterization 4.1. TML Parameterization
It is expected that it should be possible to use a configuration It is expected that it should be possible to use a configuration
reference point, such as the FEM or the CEM, to configure the TML. reference point, such as the FEM or the CEM, to configure the TML.
Some of the configured parameters may include: Some of the configured parameters may include:
o PL ID o PL ID
o Connection Type and associated data. For example if a TML uses o Connection Type and associated data. For example if a TML uses
IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses
skipping to change at page 21, line 11 skipping to change at page 24, line 11
o Allowed/Supported Connection QoS policy (or Congestion Control o Allowed/Supported Connection QoS policy (or Congestion Control
Policy) Policy)
5. Message encapsulation 5. Message encapsulation
All PL layer PDUs start with a common header [Section 5.1] followed All PL layer PDUs start with a common header [Section 5.1] followed
by a one or more TLVs [Section 5.2] which may nest other TLVs by a one or more TLVs [Section 5.2] which may nest other TLVs
[Section 5.2.1]. [Section 5.2.1].
5.1 Common Header 5.1. Common Header
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length | |version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID | | Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator | | Correlator |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Common Header Figure 7: Common Header
The message is 32 bit aligned. The message is 32 bit aligned.
Version (4 bit): Version (4 bit):
Version number. Current version is 1. Version number. Current version is 1.
rsvd (4 bit): rsvd (4 bit):
Unused at this point. A receiver should not interpret this Unused at this point. A receiver should not interpret this
field. Senders SHOULD set it to zero. field. Senders SHOULD set it to zero.
Message Type (8 bits): Message Type (8 bits):
Commands are defined in Section 6. Commands are defined in Section 6.
Length (16 bits):
length of header + the rest of the message in DWORDS (4 byte
increments).
Source ID (32 bit): Source ID (32 bit):
Dest ID (32 bit): Dest ID (32 bit):
* Each of the source and Dest IDs are 32 bit IDs which * Each of the source and Dest IDs are 32 bit IDs which are
recognize the termination points. Ideas discussed so far are unique NE-wide and which recognize the termination points of
desire to recognize if ID belongs to FE or CE by inspection. a ForCES PL message.
Suggestions for achieving this involves partitioning of the
ID allocation. Another alternative maybe to use flags to
indicate direction (this avoids partition).
* IDs will allow multi/broad/unicast
* Addressing
a. As ForCES may run between multiple CEs and FEs and over
different protocols such as IPv4 and IPv6, or directly
over Ethernet or other switching-fabric interconnects, it
is necessary to create an addressing scheme for ForCES
entities. Mappings to the underlying TML-level
addressing can then be defined as appropriate.
b. Fundamentally, unique IDs are assigned to CEs and FEs. A
split address space is used to distinguish FEs from CEs.
Even though we can assume that in a large NE there are
typically two or more orders of magnitude more FEs than
CEs, the address space is split uniformly for simplicity.
c. Special IDs are reserved for FE broadcast, CE broadcast, * IDs allow multi/broad/unicast addressing with the following
and NE broadcast. approach:
d. Subgroups of FEs belonging, for instance, to the same a. A split address space is used to distinguish FEs from
VPN, may be assigned a multicast ID. Likewise, subgroups CEs. Even though we can assume that in a large NE there
of CEs that act, for instance, in a back-up mode may be are typically two or more orders of magnitude more FEs
assigned a multicast ID. These FEs and CE multicast IDs than CEs, the address space is split uniformly for
are chosen in a distinct portion of the ID address space. simplicity.
Such a multicast ID may comprise FEs, CEs, or a mix of
both.
e. As a result, the address space allows up to 2^30 (over a b. The address space allows up to 2^30 (over a billion) CEs
billion) CEs and the same amount of FEs. and the same amount of FEs.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TS | sub-ID | |TS | sub-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: ForCES ID Format Figure 8: ForCES ID Format
f. The ForCES ID is 32 bits. The 2 most significant bits c. The 2 most significant bits called Type Switch (TS) are
called Type Switch (TS) are used to split the ID space as used to split the ID space as follows:
follows:
A. TS Corresponding ID range Assignment A. TS Corresponding ID range Assignment
B. -- ---------------------- ---------- B. -- ---------------------- ----------
C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30)
D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30)
E. 0b10 0x80000000 to 0xBFFFFFFF reserved E. 0b10 0x80000000 to 0xBFFFFFFF reserved
F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 -
(2^30 - 16) 16)
G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved
H. 0b11 0xFFFFFFFD all CEs broadcast H. 0b11 0xFFFFFFFD all CEs broadcast
I. 0b11 0xFFFFFFFE all FEs broadcast I. 0b11 0xFFFFFFFE all FEs broadcast
J. 0b11 0xFFFFFFFF all FEs and CEs J. 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast
(NE) broadcast * Multicast or broadcast IDs are used to group endpoints (such
as CEs and FES). As an example one could group FEs in some
functional group, by assigning a multicast ID. Likewise,
subgroups of CEs that act, for instance, in a back-up mode
may be assigned a multicast ID to hide them from the FE.
g. It is desirable to address multicast and/or broadcast * We donot discuss how a particular multicast ID is associated
messages to some LFB instances of a given class. For to a given group though we note that it could be done via
instance, assume FEs FEa and FEb: configuration process. The list of IDs an FE owns or is part
of are listed on the FE Object LFB.
- FEa has LFBs LFBaX1 and LFBaX2 of class X Correlator (64 bits)
This field is set by the CE to correlate ForCES Requests messages
with the corresponding Response messages from the Fe.
Essentially it is a cookie. The Correlator is handled
transparently by the FE, i.e. for a particular Request message it
will assign the same correlator value in the corresponding
Response message. In the case where the message from the CE does
not elicit a response, this field may not be useful.
- similarly, FEb has two LFBs LFBbX1 and LFBbX2 of The Correlator field could be used in many ways by the CE. For
class X. example, the CE could split the Correlator into a 32-bit
transactional identifier and 32-bit message sequence identifier.
Another example a 64 bit pointer to a context block.
A broadcast message should be addressable to only LFBs Flags(32 bits):
LFBaX1 and LFBbX1 (this can be the case for instance if Identified so far:
these two LFBs belong to the same VPN). To achieve this,
a VPN ID (3 octets OUI and 4 octets VPN Index) as defined
in RFC 2685 should be used within the ForCES message body
as a TLV.
As an alternative, a particular multicast ID MAY be 0 1 2 3
associated to a given VPN ID through some configuration 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
means. Messages delivered to such a multicast ID MUST +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
only be applied to LFBs belonging to that VPN ID. | | | | | |
|ACK| Pri | EM|TP | Reserved |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence (32 bits) - ACK: ACK indicator(2 bit)
Unique to a PDU. [Discussion: There may be impact on the effect The ACK indicator flag is only used by the CE when sending a
of subsequence numbers]. Config Message(Section 6.5.1) or a HB message (Section 6.9)
to indicate to the message receiver whether or not a config
response is required by the sender. Note that for all other
messages than Config Message this flag MUST be ignored.
Length (16 bits): The flag values are defined as below:
length of header + the rest of the message in DWORDS (4 byte
increments).
Correlator (32 bits) 'NoACK' (00) - to indicate the message receiver not to
This field is used to correlate the ForCES Requests messages send any response message back to this message sender.
(typically sent from CE to FE) with the corresponding Response
messages (typically sent from FE to CE).
Flags(32 bits): 'SuccessACK'(01) - to inidcate the message receiver to
Identified so far: send a response message back only when the message has
been successfully processed by the receiver.
- ACK indicator(2 bit) 'FailureACK'(10) - to indicate the message receiver to
The description for using the two bits is: send a response message back only when there is any
failure for the receiver to process(execute) the message.
In other words, if the message can be processed
successfully, the sender will not expect any response
from the receiver.
'NoACK' (00) 'AlwaysACK' (11) - to indicate the message receiver to
send a response message back in any case.
'SuccessACK'(01) Note that in above definitions, the term success implies a
complete execution without any failure of the message.
Anything else than a complete successful execution is defined
as a failure for the message processing. As a result, for
the execution modes (defined in Section 3.3.1.1) like
execute-all-or-none, execute-until-failure, and continue-
execute-on-failure, if any single operation among several
operations in the same message fails, it will be treated as a
failure and result in a response if the ACK indicator has
been set to 'FailureACK' or 'AlwaysACK'.
'UnsuccessACK'(10) Also note that messages other than Config and HB Messages,
whose requirements for responses are described by the message
definitions in Section 6, we summarise the default
requirements of these messages and the expected responses
below. Detailed descriptions can be found in the individual
message definitions:
'ACKAll' (11) + Association Setup Message always expects a response.
- Priority (3 bits) + Association Teardown Message, and Packet Redirect
Message, never expect responses.
+ Query Message always expects a response.
+ Any kind of response messages never expect further
responses.
- Pri: Priority (3 bits)
ForCES protocol defines 8 different levels of priority (0-7). ForCES protocol defines 8 different levels of priority (0-7).
The priority level can be used to distinguish between The priority level can be used to distinguish between
different protocol message types as well as between the same different protocol message types as well as between the same
message type. For example, the REDIRECT PACKET message could message type. For example, the REDIRECT PACKET message could
have different priorities to distinguish between Routing have different priorities to distinguish between Routing
protocols packets and ARP packets being redirected from FE to protocols packets and ARP packets being redirected from FE to
CE. The Normal priority level is 1. CE. The Normal priority level is 1.
- Throttle flag - EM: Execution mode (2 bits)
There are 3 execution modes refer to Section 3.3.1.1 for
details.
- Batch (2 bits) `execute-all-or-none` (01)
- Atomicity (1 or more bits. TBD) `execute-until-failure` (10)
5.2 Type Length Value `continue-execute-on-failure` (11)
binary 00 is reserved
- TP: Transaction phase (2 bits)
A message from the CE to the FE within a transaction could be
indicative of the different phases the transaction is in.
Refer to Section 3.3.1.1.3 for details.
`MOT (Middle of transaction)` (00)
`SOT (start of transaction)` (01)
`EOT (end of transaction)` (10)
`ABT (abort)` (11)
5.2. Type Length Value(TLV) Structuring
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | variable TLV Length | | TLV Type | variable TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Data of size TLV length) | | Value (Data of size TLV length) |
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type: Figure 10: TLV
The TLV type field is two octets, and indicates the type of data
encapsulated within the TLV.
TLV Length:
The TLV Length field is two octets, and indicates the length of
this TLV including the TLV Type, TLV Length, and the TLV data.
TLV Value: TLV Type (16):
The TLV type field is two octets, and indicates the
type of data encapsulated within the TLV.
The TLV Value field carries the data. For extensibility, the TLV TLV Length (16):
Value may be a TLV. In fact, this is the case with the The TLV Length field is two octets, and indicates
Netlink2-extension TLV. The Value encapsulated within a TLV is the length of this TLV including the TLV Type, TLV
dependent of the attribute being configured and is opaque to Length, and the TLV data.
Netlink2 and therefore is not restricted to any particular type
(example could be ascii strings such as XML, or OIDs etc).
TLV Value (variable):
The TLV Value field carries the data. For
extensibility, the TLV value may infact be a TLV.
TLVs must be 32 bit aligned. TLVs must be 32 bit aligned.
Figure 8: TLV 5.2.1. Nested TLVs
5.2.1 Nested TLVs
TLV values can be other TLVs. This provides the benefits of protocol TLV values can be other TLVs. This provides the benefits of protocol
flexibility (being able to add new extensions by introducing new TLVs flexibility (being able to add new extensions by introducing new TLVs
when needed). The nesting feature also allows easy mapping between when needed). The nesting feature also allows for an conceptual
the XML LFB definitions to binary PL representation. optimization with the XML LFB definitions to binary PL representation
(reperesented by nested TLVs).
5.2.2 Scope of the T in TLV 5.2.2. Scope of the T in TLV
The "Type" value in TLV is of global scope. This means that wherever The "Type" value in TLV is of global scope. This means that wherever
in the PDU hierachy a Type has global connotations. This is a design in the PDU hierachy a Type has global connotations. This is a design
choice to ease debugging of the protocol. choice to ease debugging of the protocol.
5.3. ILV
A slight variation of the TLV known as the ILV is introduced to allow
to the "T" to be a 32-bit index that is a ForCES element ID. The
Length part of the ILV is also 32 bits to allow of the referenced
data to be arbitrarily large in size.
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
Section 6.1.1.1.8 for discussions on usage of ILVs.
6. Protocol Construction 6. Protocol Construction
6.1 Protocol Grammar 6.1. Protocol Grammar
The protocol construction is formally defined using a BNF-like syntax The protocol construction is formally defined using a BNF-like syntax
to describe the structure of the PDU layout. This is matched to a to describe the structure of the PDU layout. This is matched to a
precise binary format later in the document. precise binary format later in the document.
Since the protocol is very flexible and hierachical in nature, it is Since the protocol is very flexible and hierachical in nature, it is
easier at times to see the visualization layout. This is provided in easier at times to see the visualization layout. This is provided in
Section 6.1.2 Section 6.1.2
6.1.1 Protocol BNF 6.1.1. Protocol BNF
The format used is based on RFC 2234. The terminals of this gramar The format used is based on RFC 2234. The terminals of this gramar
are flags, IDcount, IDs, KEYID, KEY_DATA and DATARAW, described after are flags, IDcount, IDs, KEYID, and encoded data, described after the
the grammar. grammar.
1. A TLV will have the word "TLV" at the end of its name 1. A TLV will have the word "-TLV" suffix at the end of its name
2. / is used to separate alternatives 2. An ILV will have the word "-ILV" suffix at the end of its name
3. parenthesised elements are treated as a single item 3. / is used to separate alternatives
4. * before an item indicates 0 or more repetitions 1* before an 4. parenthesised elements are treated as a single item
item indicates 1 or more repetitions
5. [] around an item indicates that it is optional (equal to *1) 5. * before an item indicates 0 or more repetitions
6. 1* before an item indicates 1 or more repetitions
7. [] around an item indicates that it is optional (equal to *0)
The BNF of the PL level PDU is as follows: The BNF of the PL level PDU is as follows:
PL level PDU := MAINHDR 1*LFBselect-TLV PL level PDU := MAINHDR [MAIN-TLV]
LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV MAIN-TLV := [LFBselect-TLV] / [REDIRECT-TLV] /
[ASResult-TLV] / [ASTreason-TLV]
LFBselect-TLV := LFBCLASSID LFBInstance OPER-TLV
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 := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV /
KEYINFO-TLV := KEYID KEY_DATA 1*PATH-DATA-TLV
DATARAW-TLV := encoded data which may nest DATARAW TLVs KEYINFO-TLV := KEYID FULLDATA-TLV
RESULT-TLV := Holds result code and optional DATARAW SPARSEDATA-TLV := encoded data that may have optionally
appearing elements
FULLDATA-TLV := encoded data element which may nest
further FULLDATA-TLVs
RESULT-TLV := Holds result code and optional FULLDATA-TLV
o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR
also defines the content. As an example the content of a "config" also defines the content. As an example the content of a "config"
message would be different from an "association" message. message would be different from an "association" message.
o MAIN-TLV is one of several TLVs that could follow the Mainheader.
The appearance of these TLVs is message type specific.
o LFBCLASSID is a 32 bit unique identifier per LFB class defined at o LFBCLASSID is a 32 bit unique identifier per LFB class defined at
class Definition time. class Definition time.
o LFBInstance is a 32 bit unique instance identifier of an LFB class o LFBInstance is a 32 bit unique instance identifier of an LFB class
o OPERATION is one of {ADD,DEL,etc.} depending on the message type o OPER-TLV uses the Type field in the TLV to uniquely identify the
type of operation i.e one of {SET, GET, DEL,etc.} depending on the
message type.
o PATH-DATA-TLV identifies the exact element targeted. It may have o PATH-DATA-TLV identifies the exact element targeted and may have
zero or more paths associated with it terminated by zero or more zero or more paths associated with it. The last PATH-DATA-TLV in
data values associated. the case of nesting of paths via the DATA construct in the case of
SET requests and GET response is terminated by encoded data or
response in the form of either FULLDATA-TLV or SPARSEDATA-TLV or
RESULT-TLV.
o PATH provides the path to the data being referenced. o PATH provides the path to the data being referenced.
* flags (16 bits) are used to further refine the operation to be * flags (16 bits) are used to further refine the operation to be
applied on the Path. More on these later. applied on the Path. More on these later.
* IDcount(16 bit): count of 32 bit IDs * IDcount(16 bit): count of 32 bit IDs
* IDs: zero or more 32bit IDs (whose count is given by IDcount) * IDs: zero or more 32bit IDs (whose count is given by IDcount)
defining the main path. Depending on the flags, IDs could be defining the main path. Depending on the flags, IDs could be
field IDs only or a mix of field and dynamic IDs. Zero is used field IDs only or a mix of field and dynamic IDs. Zero is used
for the special case of using the entirety of the containing for the special case of using the entirety of the containing
context as the result of the path. context as the result of the path.
o SELECTOR is an optional construct that further defines the PATH. o SELECTOR is an optional construct that further defines the PATH.
Currently, the only defined selector is the KEYINFO-TLV, used for Currently, the only defined selector is the KEYINFO-TLV, used for
selecting an array entry by the value of a key field. The selecting an array entry by the value of a key field. The
presence of a SELECTOR is correct only when the flags also presence of a SELECTOR is correct only when the flags also
skipping to change at page 27, line 41 skipping to change at page 33, line 22
selecting an array entry by the value of a key field. The selecting an array entry by the value of a key field. The
presence of a SELECTOR is correct only when the flags also presence of a SELECTOR is correct only when the flags also
indicate its presence. A mismatch is a protocol format error. indicate its presence. A mismatch is a protocol format error.
o A KEYINFO TLV contains information used in content keying. o A KEYINFO TLV contains information used in content keying.
* A KeyID is used in a KEYINFO TLV. It indicates which key for * A KeyID is used in a KEYINFO TLV. It indicates which key for
the current array is being used as the content key for array the current array is being used as the content key for array
entry selection. entry selection.
* KEY_DATA is the data to look for in the array, in the fields * The key's data is the data to look for in the array, in the
identified by the keyfield. The information is encoded fields identified by the keyfield. The information is encoded
according to the rules for the contents of a DATARAW, 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 DATARAW or 1 or more further PATH-DATA o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1
selection DATARAW is only allowed on SET requests, or on responses or more further PATH-DATA selection. FULLDATA and SPARSEDATA are
which return content information (GET Response for example.) only allowed on SET requests, or on responses which return content
PATH-DATA may be included to extent the path on any request. information (GET-RESPONSE for example). PATH-DATA may be included
to extend the path on any request.
* Note: Nested PATH-DATA TLVs are supported as an efficiency * Note: Nested PATH-DATA TLVs are supported as an efficiency
measure to permit common subexpression extraction. measure to permit common subexpression extraction.
* DATARAW contains "the data" whose path is selected. * FULLDATA and SPARSEDATA contain "the data" whose path has been
selected by the PATH. Refer to Section 6.1.1.1 for details.
o RESULT contains the indication of whether the individual SET o RESULT contains the indication of whether the individual SET
succeeded. If there is an indication for verbose response, then succeeded. If there is an indication for verbose response, then
SETRESULT will also contain the DATARAW showing the data that was SET-RESPONSE will also contain the FULLDATA TLV showing the data
set. RESULT-TLV is included on the assumption that individual that was set. RESULT-TLV is included on the assumption that
parts of a SET request can succeed or fail separately. individual parts of a SET request can succeed or fail separately.
In summary this approach has the following characteristic: In summary this approach has the following characteristic:
o There can be one or more LFB Class + InstanceId combo targeted in o There can be one or more LFB Class + InstanceId combo targeted in
a message (batch) a message (batch)
o There can one or more operations on an addressed LFB classid+ o There can one or more operations on an addressed LFB classid+
instanceid combo(batch) instanceid combo(batch)
o There can be one or more path targets per operation (batch) o There can be one or more path targets per operation (batch)
o Paths may have zero or more data values associated (flexibility o Paths may have zero or more data values associated (flexibility
and operation specific) and operation specific)
It should be noted that the above is optimized for the case of a It should be noted that the above is optimized for the case of a
single classid+instance targeting. To target multiple instances single classid+instance targeting. To target multiple instances
skipping to change at page 28, line 33 skipping to change at page 34, line 16
o There can be one or more path targets per operation (batch) o There can be one or more path targets per operation (batch)
o Paths may have zero or more data values associated (flexibility o Paths may have zero or more data values associated (flexibility
and operation specific) and operation specific)
It should be noted that the above is optimized for the case of a It should be noted that the above is optimized for the case of a
single classid+instance targeting. To target multiple instances single classid+instance targeting. To target multiple instances
within the same class, multiple LFBselect are needed. within the same class, multiple LFBselect are needed.
6.1.1.1 Discussion on Grammar 6.1.1.1. Discussion on Grammar
Data is packed in such a way that a receiver of such data with In the case of FULLDATA encoding, data is packed in such a way that a
knowledge of the path can correlate what it means by infering in the receiver of such data with knowledge of the path can correlate what
LFB definition. This is an optimization that helps reducing the it means by infering in the LFB definition. This is an optimization
amount of description for the data in the protocol. that helps reducing the amount of description for the data in the
protocol.
In other words: In other words:
It is assumed that the type of the data can be inferred by the It is assumed that the type of the data can be inferred by the
context in which data is used. Hence, data will not include its type context in which data is used. Hence, data will not include its type
information. The basis for the inference is typically the LFB class information. The basis for the inference is typically the LFB class
id and the path. id and the path.
6.1.1.1.1 Data Packing Rules It is expected that a substantial amount of operations in ForCES will
need to reference optional data within larger structures. For this
reason, the SPARSEDATA encoding is introduced to make it easier to
encapsulate optionaly appearing data elements.
The scheme for packaging data used in this doc adheres to the 6.1.1.1.1. Data Packing Rules
following rules:
o The Value of DATARAW TLV will contain the data being transported. The scheme for encoding data used in this doc adheres to the
This data will be as was described in the LFB definition. following rules:
o By definition in the Forces protocol, all TLVs are 32 bit aligned. o The Value ("V" of TLV) of FULLDATA TLV will contain the data being
Therefore because DATARAW is a TLV, elements not aligned in 32 bit transported. This data will be as was described in the LFB
values will be padded. definition.
* As an example a 16 bit value will have an extra 16 bit pad; o Variable sized data within a FULLDATA TLV will be encapsulated
however two 16 bits values in a structure will be shipped inside another FULLDATA TLV inside the V of the outer TLV. For
together with no padding etc. example of such a setup refer to Appendix E and Appendix D.
o Variable sized data will be encapsulated inside another DATARAW o In the case of FULLDATA TLVs:
TLV inside the V of the outer TLV. For example of this see
Appendix D example 13.
o When a table is refered in the PATH (ids), then the RAWDATA's V o When a table is refered to in the PATH (ids) of a PATH-DATA-TLV,
will contain that tables row content prefixed by its 32 bit index/ then the FULLDATA's "V" will contain that table's row content
subscript OTOH, when PATH flags are 00, the PATH may contain an prefixed by its 32 bit index/subscript. OTOH, when PATH flags are
index pointing to a row in table; in such a case, the RAWDATA's V 00, the PATH may contain an index pointing to a row in table; in
will only contain the content with the index in order to avoid such a case, the FULLDATA's "V" will only contain the content with
ambiguity. the index in order to avoid ambiguity.
6.1.1.1.2 Path Flags 6.1.1.1.2. Path Flags
The following flags are currently defined: The following flags are currently defined:
o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present
following this path information, and should be considered in following this path information, and should be considered in
evaluating the path. evaluating the path.
o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set.
This must only be used on a create operation. If set, this This must only be used on a create operation. If set, this
indicates that although the path identifies an array, the SET indicates that although the path identifies an array, the SET
operation should be applied to the first unused element in the operation should be applied to the first unused element in the
array. The result of the operation will not have this flag set, array. The result of the operation will not have this flag set,
and will have the assigned index in the path. and will have the assigned index in the path.
6.1.1.1.3 Relation of operational flags with global message flags 6.1.1.1.3. Relation of operational flags with global message flags
Should be noted that other applicable flags such as atomicity Should be noted that other applicable flags such as atomicity
indicators as well as verbosity result formaters are in the main indicators as well as verbosity result formaters are in the main
headers flags area. headers flags area.
6.1.1.1.4 Content Path Selection 6.1.1.1.4. Content Path Selection
The KEYINFO TLV describes the KEY as well as associated KEY data. The KEYINFO TLV describes the KEY as well as associated KEY data.
KEYs, used for content searches, are restricted and described in the KEYs, used for content searches, are restricted and described in the
LFB definition. LFB definition.
6.1.1.1.5 Operation TLVs 6.1.1.1.5. LFB select TLV
It is assumed that specific operations are identified by the type The LFB select TLV is an instance of TLV defined in Section 5.2. The
code of the TLV. And that response are also identified by specific definition is as below:
TLV opcodes
6.1.1.1.6 SET and GET Relationship 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: PL PDU layout
Type:
The type of the TLV is "LFBselect"
Length:
Length of the TLV including the T and L fields, in bytes.
LFB Class ID:
This field uniquely recognizes the LFB class/type.
LFB Instance ID:
This field uniquely identifies the LFB instance.
Operation TLV:
It describes an operation nested in the LFB select TLV. Note
that usually there SHOULD be at least one Operation TLV present
for an LFB select TLV, but for Association Setup Message defined
in Section 6.4.1, Operation TLV is totally optional, therefore
there might be no any Operation TLV followed in the LFB select
TLV there.
6.1.1.1.6. Operation TLV
The Operation TLV is an instance of TLV Idefined in Section 5.2. It
is assumed that specific operations are identified by the Type code
of the TLV. Definitions for individual Types of operation TLVs are
in corresponding message description sections followed.
SET and GET Requests do not have result information (they are
requests). SET and GET Responses have result information. SET and
GET Responses use SET-RESPONSE and GET-RESPONSE operation TLVs.
For a GET responses, individual gets which succeed will have FULLDATA
TLVs added to the leaf paths to carry the requested data. For GET
elements that fail, instead of the FULLDATA TLV there will be a
RESULT TLV.
For a SET response, each FULLDATA or or SPARSEDATA TLV in the
original request will be replaced with a RESULT TLV in the response.
If the request was for Ack-fail, then only those items which failed
will appear in the response. If the request was for ack-all, then
all elements of the request will appear in the response with RESULT
TLVs.
Note that if a SET request with a structure in a FULLDATA is issued,
and some field in the structure is invalid, the FE will not attempt
to indicate which field was invalid, but rather will indicate that
the operation failed. Note further that if there are multiple errors
in a single leaf path-data / FULLDATA, the FE can select which error
it chooses to return. So if a FULLDATA for a SET of a structure
attempts to write one field which is read only, and attempts to set
another field to an invalid value, the FE can return whatever error
it likes.
A SET operation on a variable length element with a length of 0 for
the item is not the same as deleteing it. If the CE wishes to delete
then the DEL operation should be used whether the the path refers to
an array element or an optional structure element.
6.1.1.1.7. Result TLV
A RESULT TLV contains a integer (probably 4 bytes, but we only need 1
byte) value.
The defined values are
0 = success
1 = no such object
2 = permission denied
3 = invalid value (the encoded data could not validly be stored in
the field)
4 = invalid array creation (when the subscript in an array create is
not allowed)
255 = unspecified error (for when the FE can not decide what went
wrong)
6.1.1.1.8. DATA TLV
A FULLDATA TLV has "T"= FULLDATA, and a 16bit Length followed by the
data value/contents. Likewise, a SPARSEDATA TLV has "T" =
SPARSEDATA, a 16bit Length followed by the data value/contents. In
the case of the SPARSEDATA each element in the Value part of the TLV
will be further encapsulated in an ILV. Rules:
1. Both ILVs and TLVs MUST 32 bit aligned. If need be they MUST be
padded to achieve the alignement.
2. FULLDATA TLV may be used at a particular path only if every
element at that path level is present. This requirement holds
whether the fields are fixed or variable length, mandatory or
optional.
* If a FULLDATA TLV is used, the encoder MUST layout data for
each element ordered by the order in which the data was
defined in the LFB specification. This ensures the decoder is
guaranteed to retrieve the data.
* In the case of a SPARSEDATA we dont need to order since the
"I" in the ILV uniquely identifies the element.
3. Inside a FULLDATA TLV
* The values for atomic, fixed-length fields are given without
any TLV or ILV encapsulation.
* The values for atomic, variable-length fields are given inside
FULLDATA TLVs.
4. Inside a SPARSE TLV
* the values for atomic fields may be given with ILVs (32-bit
index, 32-bit length)
5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot
contain a FULLDATA. This is because it is hard to disambiguate
ILV since an I is 32 bit and a T is 16 bit.
6. A FULLDATA can also contain a FULLDATA for variable sized
elements. The decoding disambiguation is assumed from rule #3
above.
6.1.1.1.9. SET and GET Relationship
It is expected that a GET-RESPONSE would satisfy the following It is expected that a GET-RESPONSE would satisfy the following
desires: desires:
o it would have exactly the same path definitions as that was sent o it would have exactly the same path definitions as that was sent
in the GET. The only difference being a GET-RESPONSE will contain in the GET. The only difference being a GET-RESPONSE will contain
DATARAW TLVs. FULLDATA TLVs.
o it should be possible that one would take the same GET-RESPONSE o it should be possible that one would take the same GET-RESPONSE
and convert it to a SET-REPLACE successfully by merely changing and convert it to a SET-REPLACE successfully by merely changing
the T in the operational TLV. the T in the operational TLV.
o There are exceptions to this rule: o There are exceptions to this rule:
1. When a KEY selector is used with a path in a GET operation, 1. When a KEY selector is used with a path in a GET operation,
that selector is not returned in the GET-RESPONSE; instead the that selector is not returned in the GET-RESPONSE; instead the
cooked result is returned. Refer to the examples using KEYS cooked result is returned. Refer to the examples using KEYS
to see this. to see this.
2. When dumping a whole table in a GET, the GET-RESPONSE, merely 2. When dumping a whole table in a GET, the GET-RESPONSE, merely
editing the T to be SET will endup overwritting the table. editing the T to be SET will endup overwritting the table.
6.1.2 Protocol Visualization 6.1.2. Protocol Visualization
The figure below shows a general layout of the PL PDU. A main header The figure below shows a general layout of the PL PDU. A main header
is followed by one or more LFB selections each of which may contain is followed by one or more LFB selections each of which may contain
one or more operation. one or more operation.
main hdr (Config in this case) main hdr (Config in this case)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
skipping to change at page 31, line 49 skipping to change at page 40, line 49
| |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID +-- LFBCLASSID
| |
+-- LFBInstance +-- LFBInstance
. .
. .
. .
Figure 10: PL PDU layout Figure 13: PL PDU logical layout
The figure below shows an example general layout of the operation The figure below shows an example general layout of the operation
within a targetted LFB selection. The idea is to show the different within a targetted LFB selection. The idea is to show the different
nesting levels a path could take to get to the target path. nesting levels a path could take to get to the target path.
T = SET-CREATE T = SET-CREATE
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
skipping to change at page 32, line 31 skipping to change at page 41, line 31
| | | |
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| + -- T = KEYINFO | + -- T = KEYINFO
| | + -- KEY_ID | | + -- KEY_ID
| | + -- KEY_DATA | | + -- KEY_DATA
| | | |
| + -- T = DATARAW | + -- T = FULLDATA
| + -- data | + -- data
| |
| |
T = SET-REPLACE T = SET-REPLACE
| | | |
| +- T = Path-data | +- T = Path-data
| | | | | |
| | + -- flags | | + -- flags
| | + -- IDCount | | + -- IDCount
| | + -- IDs | | + -- IDs
| | | | | |
| | + -- T = DATARAW | | + -- T = FULLDATA
| | + -- data | | + -- data
| +- T = Path-data | +- T = Path-data
| | | |
| + -- flags | + -- flags
| + -- IDCount | + -- IDCount
| + -- IDs | + -- IDs
| | | |
| + -- T = DATARAW | + -- T = FULLDATA
| + -- data | + -- data
T = DEL T = DEL
| |
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
| |
+- T = Path-data +- T = Path-data
skipping to change at page 33, line 35 skipping to change at page 42, line 35
+ -- IDs + -- IDs
+ -- T = KEYINFO + -- T = KEYINFO
| + -- KEY_ID | + -- KEY_ID
| + -- KEY_DATA | + -- KEY_DATA
+- T = Path-data +- T = Path-data
| |
+ -- flags + -- flags
+ -- IDCount + -- IDCount
+ -- IDs + -- IDs
Figure 11: Sample operation layout Figure 14: Sample operation layout
6.2 Core ForCES LFBs 6.2. Core ForCES LFBs
There are three LFBs that are used to control the operation of the There are two LFBs that are used to control the operation of the
ForCES protocol and to interact with FEs and CEs: ForCES protocol and to interact with FEs and CEs:
FE protocol LFB FE Protocol LFB
FE LFB FE Object LFB
Although these LFBs have the same form and interface as other LFBs, Although these LFBs have the same form and interface as other LFBs,
they are special in many respects: they have fixed well-known LFB they are special in many respects: they have fixed well-known LFB
Class and Instance IDs. They are statically defined (no dynamic Class and Instance IDs. They are statically defined (no dynamic
instantiation allowed) and their status cannot be changed by the instantiation allowed) and their status cannot be changed by the
protocol: any operation to change the state of such LFBs (for protocol: any operation to change the state of such LFBs (for
instance, in order to disable the LFB) must result in an error. instance, in order to disable the LFB) must result in an error.
Moreover, these LFBs must exist before the first ForCES message can Moreover, these LFBs must exist before the first ForCES message can
be sent or received. All attributes in these LFBs must have pre- be sent or received. All attributes in these LFBs must have pre-
defined default values. Finally, these LFBs do not have input or defined default values. Finally, these LFBs do not have input or
output ports and do not integrate into the intra-FE LFB topology. output ports and do not integrate into the intra-FE LFB topology.
6.2.1 FE Protocol LFB 6.2.1. FE Protocol LFB
The FE Protocol LFB is a logical entity in each FE that is used to The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB Class ID is control the ForCES protocol. The FE Protocol LFB Class ID is
assigned the value 0x1. The FE LFB Instance ID is assigned the value assigned the value 0x1. The FE Protocol LFB Instance ID is assigned
0x1. There MAY be one and only one instance of the FE Protocol LFB the value 0x1. There MAY be one and only one instance of the FE
in an FE. The values of the attributes in the FE Protocol LFB have Protocol LFB in an FE. The values of the attributes in the FE
pre-defined default values that are specified here. Unless explicit Protocol LFB have pre-defined default values that are specified here.
changes are made to these values using Config messages from the CE, Unless explicit changes are made to these values using Config
these default values MUST be used for the operation of the protocol. messages from the CE, these default values MUST be used for the
operation of the protocol.
The formal definition of the FE Protocol LFB can be found in The formal definition of the FE Protocol LFB can be found in
Appendix C Appendix C
The FE Protocol LFB consists of the following elements: The FE Protocol LFB consists of the following elements:
o FE Protocol events that can be subscribed/unsubscribed:
* FE heartbeat
o FE Protocol capabilities (read-only): o FE Protocol capabilities (read-only):
* Supported ForCES protocol version(s) by the FE * Supported ForCES protocol version(s) by the FE
* Supported ForCES FE model(s) by the FE * Any TML capability description(s)
* Some TML capability description(s)
o FE Protocol attributes (can be read and set): o FE Protocol attributes (can be read and set):
* Current version of the ForCES protocol * Current version of the ForCES protocol
* Current version of the FE model
* FE unicast ID * FE unicast ID
* FE multicast ID(s) (list) * FE multicast ID(s) list - this is a list of multicast IDs that
the FE belongs to. These IDs are configured by the CE.
* Association Expiry Timer. Defualt Value = 900 msec
* Heartbeat Interval. Defualt Value = 300 msec
* Primary CE
* FE failover and restart policy - This specifies the behavior of
the FE during a CE failure and restart time interval. For
example, this would specify if the FE should continue running
or stop operation during a CE failure in the NE.
* CE failover and restart policy - - This specifies the behavior
of the CE during a FE failure and restart time interval. For
example, this would specify if the CE should continue running
or stop operation during a FE failure in the NE.
6.2.2 FE Object LFB
The FE Object LFB is a logical entity in each FE and contains * CE heartbeat policy - This policy, along with the parameter 'CE
attributes relative to the FE itself, and not to the operation of the Heartbeat Dead Interval (CE HDI)' as described below defines
ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The the operating parameters for the FE to check the CE liveness.
FE LFB Instance ID is assigned the value 0x1. There must always be The policy values with meanings are listed as below:
one and only one instance of the FE LFB in an FE.
The formal definition of the FE Object LFB can be found in [FE-MODEL] 0(default) - This policy specifies that CE will send a
Heartbeat Message to FE whenever CE reaches a time interval
within which no other PL messages were sent from CE to FE;
refer to Section 3.3.2 for details. The CE HDI attribute as
described below is tied to this policy. If the FE has not
received any PL messages within CE HDI period it declares
the connectivity lost. The CE independently chooses the
time interval to send the Heartbeat messages to FE - care
must be exercised to ensure the CE->FE HB interval is
smaller than the CE HDI assigned.
The FE LFB consists of the following elements: 1 - The CE will not generate any HB messages. This actually
means CE does not want the FE to check the CE liveness.
FE Events: Others - reserved.
* FEAllEvents: subscribing to this corresponds to subscribing to * CE Heartbeat Dead Interval (CE HDI) - The time interval the FE
all events below uses to check the CE liveness. If FE has not received any
messages from CE within this time interval, FE deduces lost
connectivity which implies that the CE is dead or the
association to the CE is lost. Default value 30 s.
* FEStatusChange: events that signal FE Status: * FE heartbeat policy - This policy, along with the parameter 'FE
Heartbeat Interval (FE HI)', define the operating parameters
for how the FE should behave so that the CE can deduce its
liveliness. The policy values and the meanings are:
+ Up 0(default) - The FE should not generate any Heartbeat
messages. In this scenario, the CE is responsible for
checking FE liveness by setting the PL header ACK flag of
the message it sends to AlwaysACK. The FE responds to CE
whenever CE sends such Heartbeat Request Message. Refer to
Section 6.9 and Section 3.3.2 for details.
+ Down 1 - This policy specifies that FE must actively send a
Heartbeat Message if it reaches the time interval assigned
by the FE HI as long as no other messages were sent from FE
to CE during that interval as described in Section 3.3.2.
+ Active Others - Reserved.
+ Inactive * FE Heartbeat Interval (FE HI) - The time interval the FE should
use to send HB as long as no other messages were sent from FE
to CE during that interval as described in Section 3.3.2. The
deafult value for a FE HI is 500ms.
+ Failover * Primary CEID - The CEID that the FE is associated with.
* FE DoS alert * Backup CEs - The list of backup CEs an FE is associated with.
Refer to Section 8 for details.
* FE capability change * FE restart policy - This specifies the behavior of the FE
FE attributes: during a FE restart. The restart may be from a FE failure or
other reasons that have made FE down and then need to restart.
The values are defined as below:
* FEStatus: to set the FE mode as: 0(default)- just restart the FE from scratch. In this case,
the FE should start from pre-association phase definitely.
+ Active 1 - restart the FE from an intermediate state. In this
case, the FE itself decides from which state it restarts.
For example, if the FE still keeps enough infomation of pre-
association phase after some failure, it then has the right
just to start from post-associatin phase with this policy
case.
+ Inactive Others - Reserved
+ Shutdown * CE failover policy - This specifies the behavior of the FE
during a CE failure and restart time interval, or when the FE
loses the CE association. It should be noted that this policy
in the case of HA only takes effect after total failure to
connect to a new CE. A timeout parameter, the CE Timeout
Interval (CE TI) is associated with this attribute. Values of
this policy are defined as below:
* FELFBInstancelist 0(default) - The FE should continue running and do what it
can even without an associated CE. This basically makes the
FE support CE Graceful restart. Note that if the CE still
has not been restarted or hasn't been associated back to the
FE, after the CE TI has expired, the FE will go
operationally down.
* FENeighborList 1 - FE should go down to stop functioning immediately.
* MIID table: a list of virtual LFB Instance IDs that map to a 2 - FE should go inactive to temporarily stop functioning.
list of Instance IDs of LFBs in that FE If the CE still has not been restarted after a time interval
of specified by the CE TI, the FE will go down completely.
* FE Behavior Exp. Timer Others - Reserved
* HA Mode * CE Timeout Interval (CE TI) - The time interval associated with
the CE failover policy case '0' and '2'. The default value is
set to 300 seconds. Note that it is advisable to set the CE TI
value much higher than the CE Heartbeat Dead Interval (CE HDI)
since the effect of expiring this parameter is devastating to
the operation of the FE.
* FE DoS protection policy 6.2.2. FE Object LFB
* FEPrivateData: Proprietary info such as name, vendor, model. The FE Object LFB is a logical entity in each FE and contains
attributes relative to the FE itself, and not to the operation of the
ForCES protocol.
* Inter-FE topology Intra-FE topology The formal definition of the FE Object LFB can be found in [FE-
MODEL]. The model captures the high level properties of the FE that
the CE needs to know to begin working with the FE. The class ID for
this LFB Class is also assigned in [FE-MODEL]. The singular instance
of this class will always exist, and will always have instance ID 1
within its class. It is common, although not mandatory, for a CE to
fetch much of the attribute and capability information from this LFB
instance when the CE begins controlling the operation of the FE.
6.3 Semantics of message Direction 6.3. Semantics of message Direction
Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. Recall: The PL protocol provides a master(CE)-Slave(FE) relationship.
The LFBs reside at the FE and are controlled by CE. The LFBs reside at the FE and are controlled by CE.
When messages go from the CE, the LFB Selector (Class and instance) When messages go from the CE, the LFB Selector (Class and instance)
refers to the destination LFB selection which resides in the FE. refers to the destination LFB selection which resides in the FE.
When messages go from the FE->CE, the LFB Selector (Class and When messages go from the FE->CE, the LFB Selector (Class and
instance) refers to the source LFB selection which resides in the FE. instance) refers to the source LFB selection which resides in the FE.
6.4 Association Messages 6.4. Association Messages
The ForCES Association messages are used to establish and teardown The ForCES Association messages are used to establish and teardown
associations between FEs and CEs. associations between FEs and CEs.
6.4.1 Association Setup Message 6.4.1. Association Setup Message
This message is sent by the FE to the CE to setup a ForCES This message is sent by the FE to the CE to setup a ForCES
association between them. This message could also be used by CEs to association between them. This message could also be used by CEs to
join a ForCES NE, however CE-to-CE communication is not covered by join a ForCES NE, however CE-to-CE communication is not covered by
this protocol. this protocol.
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= 'Association The Message Type in the header is set MessageType=
Setup'. The ACK flag in the header is ignored, because the setup 'AssociationSetup'. The ACK flag in the header MUST be ignored,
message will always expect to get a response from the message and the association setup message always expects to get a response
receiver (CE) whether the setup is successful or not. The Src ID from the message receiver (CE) whether the setup is successful or
not. The Correlator field in the header is set, so that FE can
correlate the response coming back from CE correctly. The Src ID
(FE ID) may be set to O in the header which means that the FE (FE ID) may be set to O in the header which means that the FE
would like the CE to assign a FE ID for the FE in the setup would like the CE to assign a FE ID for the FE in the setup
response message. response message.
Message body: Message body:
The LFB selection may point to the FE Object and/or FE Protocol The association setup message body optionally consist of one or
LFBs and more than one attribute may be announced in this message more LFB select TLV as described in Section 6.1.1.1.5. The
using GET-REPONSE to let the FE declare its configuration association setup message only operates toward the FE Object and
parameters in an unsolicited manner. The layout is: FE Protocol LFBs, therefore, the LFB class ID in the LFB select
TLV only points to these two kinds of LFBs. There is only one FE
object LFB and one FE protocol LFB per FE, therefore, the LFB
instance IDs for the FE object LFB and the FE protocol LFB are
usually assigned to the value 0x1.
The Operation TLV in the LFB select TLV is defined as a 'REPORT'
operation. More than one attribute may be announced in this
message using REPORT operation to let the FE declare its
configuration parameters in an unsolicited manner. These may
contain attributes like the Heart Beat Interval parameter, etc.
The Operation TLV for event notificationis is defined below.
Operation TLV for Association Setup:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Only one operation type is defined for the association setup
message:
Type = "REPORT" --- this type of operation is for FE to
report something to CE.
PATH-DATA-TLV for REPORT:
This is generically a PATH-DATA-TLV format that has been defined
in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF
definition. The PATH-DATA-TLV for REPORT operation MAY contain
FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data
format. The RESULT-TLV is defined in Section 6.1.1.1.7 and the
FULLDATA-TLV is defined in Section 6.1.1.1.8.
To better illustrate the above PDU format, we show a tree structure
for the format as below:
main hdr (eg type = Association setup) main hdr (eg type = Association setup)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = FE object | +-- LFBCLASSID = FE object
| | | |
| | | |
| +-- LFBInstance = 0x1 | +-- LFBInstance = 0x1
skipping to change at page 38, line 25 skipping to change at page 48, line 25
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
| |
| |
+-- LFBInstance = 0x1 +-- LFBInstance = 0x1
| |
+-- Path-data to one or more attibutes +-- Path-data to one or more attibutes
including suggested HB parameters including suggested HB parameters
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 Figure 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Attributes path and data ~
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Protocol Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Attributes path and data ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
Type (16 bits):
LFB Select
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
FE Object and Protocol LFBs:
These contains the FE parameters e.g. HBI may be exchanged with
the CE using the FE Protocol LFB.
6.4.2 Association Setup Response Message 6.4.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= 'Setup The Message Type in the header is set MessageType=
Response'. The ACK flag in the header is always ignored, because 'AssociationSetupResponse'. The ACK flag in the header MUST be
the setup response message will never expect to get any more ignored, and the setup response message never expects to get any
response from the message receiver (FE). The Dst ID in the more response from the message receiver (FE). The Correlator
header will be set to some FE ID value assigned by the CE if the field in the header MUST keep the same as that of the association
FE had requested that in the setup message (by SrcID = 0). setup message to be responded, so that the association setup
message sender can correlate the response correctly. The Dst ID
in the header will be set to some FE ID value assigned by the CE
if the FE had requested that in the setup message (by SrcID = 0).
Message body: Message body:
The LFB selection may point to the FE Object and/or FE Protocol The association setup response message body only consists of one
LFBs and more than one attribute may be announced in this TLV, the Association Result TLV, the format of which is as
message. The layout is: follows: is:
main hdr (eg type = Association setup response)
|
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
| |
| +--- T = Operation = SET
| |
| +-- Path-data to one or more attibutes
| including FE NAME
|
+--- T = LFBselect
|
+-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
|
+--- T = Operation = SET
|
+-- Path-data to one or more attibutes
eg HB parameters
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 = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation SET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Attributes path and data ~
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Protocol Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation SET | Length | | Type = ASRresult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Association Setup Result |
~ ~
~ Attributes path and data ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13
Type (16 bits): Type (16 bits):
LFB Select The type of the TLV is "ASRresult".
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in bytes. Length of the TLV including the T and L fields, in bytes.
FE Object LFB: Association Setup Result (32 bits):
The FE parameters e.g. HBI may be exchanged using this LFB.
Result (16 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 = too many associations 2 = too many associations
3 = permission denied 3 = permission denied
6.4.3 Association Teardown Message 6.4.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= "Asso. The Message Type in the header is set MessageType=
Teardown". The ACK flag in the header is always ignored, because "AssociationTeardown". The ACK flag MUST be ignored, and the
the teardown message will never expect to get any response from association teardown message never expects to get any further
the message receiver. response from the message receiver. The correlator field in the
header is also ignored owing to no further response expected.
Message Body: Message Body:
The association teardown message body consists of LFBSelect & The association teardown message body only consists of one TLV,
FEReason TLV, the format of which is as follows: the Association Teardown Reason TLV, the format of which is as
follows:
main hdr (eg type = Association tear)
|
|
|
+--- T = Teardown Reason
|
+-- Teardown Reason code
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 = Teardown reason | Length | | Type = ASTreason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Reason | | Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14
Type (16 bits): Type (16 bits):
LFB Select The type of the TLV is "ASTreason".
Length (16 bits): Length (16 bits):
Length of the TLV including the T and L fields, in bytes. Length of the TLV including the T and L fields, in bytes.
Teardonw Reason (32 bits): Teardonw 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.
0 - normal teardown by administrator 0 - normal teardown by administrator
1 - error - out of memory 1 - error - loss of heartbeats
2 - error - application crash 2 - error - out of bandwidth
3 - error - out of memory
4 - error - application crash
255 - error - other or unspecified 255 - error - other or unspecified
6.5 Configuration Messages 6.5. Configuration Messages
The ForCES Configuration messages are used by the CEs to configure The ForCES Configuration messages are used by CE to configure the FEs
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.
6.5.1 Config Message 6.5.1. Config Message
This message is sent by the CE to the FE to configure FE or LFB This message is sent by the CE to the FE to configure LFB attributes
attributes. 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 FE and LFB events. unsubscribe to LFB events.
As usual, a config message is composed of a common header followed by
a message body that consists of one or more TLV data format.
Detailed description of the message is as below.
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= 'Config'. The The Message Type in the header is set MessageType= 'Config'. The
ACK flag in the header is can be used by the CE to turn off any ACK flag in the header can be set to any value defined in
response from the FE. The default behavior is to turn on the ACK Section 5.1, to inidcate whether or not a response from FE is
to get the config response from the FE. expected by the message ( the flag is set to 'NoACK' or
'AlwaysACK'), or to indicate in which case a response is
generated (the flag is set to 'SuccessACK' or 'FailureACK'). The
default behavior for the ACK flag is set to always expect a full
response from FE. This happens when the ACK flag is not set to
any defined value. The correlator field in the messge header
MUST be set if a response is expected, so that CE can correlate
the response correctly. The correlator field can be ignored if
no response is expected.
Message body: Message body:
The Config message body consists of one or more TLVs, the format The config message body MUST consist of at least one LFB select
of a single (LFB) TLV is as follows: TLV as described in Section 6.1.1.1.5. The Operation TLV in the
LFB select TLV is defined below.
Operation TLV for Config:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
The operation type for config message. two types of operations
for the config message are defined:
Type = "SET" --- this operation is to set LFB attributes
Type = "DEL" --- this operation to delete some LFB
attributes
PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format that has been defined
in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF
definition. The restriction on the use of PATH-DATA-TLV for SET
operation is, it MUST contain either a FULLDATA or SPARSEDATA
TLV(s), but MUST NOT contain any RESULT-TLV. The restriction on
the use of PATH-DATA-TLV for DEL operation is it MAY contain
FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT-
TLV. The RESULT-TLV is defined in Section 6.1.1.1.7 and FULLDATA
and SPARSEDATA TLVs is defined in Section 6.1.1.1.8.
*Note: For Event subscription, the events will be defined by the
individual LFBs.
To better illustrate the above PDU format, we show a tree structure
for the format as below:
main hdr (eg type = config) main hdr (eg type = config)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = target LFB class | +-- LFBCLASSID = target LFB class
| | | |
| | | |
| +-- LFBInstance = target LFB instance | +-- LFBInstance = target LFB instance
| | | |
| | | |
| +-- T = operation { SET, DEL } | +-- T = operation { SET }
| | |
| | +-- // one or more path targets
| | // discussed later
| |
| +-- T = operation { SET, DEL }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // discussed later | | // associated with FULL or SPARSEDATA TLV(s)
| | | |
| +-- T = operation { SET, DEL } | +-- T = operation { DEL }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // discussed later
| |
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 = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation (SET) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Config path ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operations (DEL) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Config path ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
Type (16 bits): 6.5.2. Config Response Message
LFB Select.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
LFB Class ID (16 bits):
This field uniquely recognizes the LFB class/type.
LFB Instance ID (16 bits):
This field uniquely identifies the LFB instance.
Type (16 bits):
The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT
SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Config path + Data (variable length):
This will carry LFB specific data The config data will be in the
form of a TLV. Should be noted only a CREATE, REPLACE will have
data while the rest will only carry path information of what to
DELete or GET.
*Note: FE Activate/Deactivate, Shutdown FE commands for State
Maintenance will be sent using Config messages.
*Note: For Event subscription, the events will be defines by the
individual LFBs.
6.5.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, because Response'. The ACK flag in the header is always ignored, and the
the config response message will never expect to get any more config response message never expects to get any further response
response from the message receiver (CE). from the message receiver (CE). The Correlator field in the
header MUST keep the same as that of the config message to be
responded, so that the config message sender can correlate the
response with the original message correctly.
Message body: Message body:
The Config response message body consists of one or more TLVs, TThe config message body MUST consist of at least one LFB select
the format of a single TLV is as follows: TLV as described in Section 6.1.1.1.5. The Operation TLV in the
LFB select TLV is defined below.
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 Operation TLV for Config Response:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Result | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-data TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operations (DEL-RESP) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-data TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result TLV | | PATH-DATA-TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 Type:
The operation type for config response message. Two types of
Type (16 bits): operations for the config response message are defined:
LFB Select.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
LFB Class ID (16 bits):
This field uniquely recognizes the LFB class/type.
LFB Instance ID (16 bits):
This field uniquely identifies the LFB instance.
Type (16 bits):
The operations are same as those defined for Config messages.
Length (16 bits):
Length of the TLV including the T and L fields, in bytes.
Operation Result (16 bits):
This indicates the overall result of the config operation,
whether it was successful or it failed.
0 = success
1 = FE ID invalid
3 = permission denied Type = "SET-RESPONSE" --- this operation is for the
response of SET operation of LFB attributes
Path-data TLV Type = "DEL-RESPONSE" --- this operation is for the
response of DELete operation of LFB attributes
Result TLV PATH-DATA-TLV:
This is generically a PATH-DATA-TLV format that has been defined
in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF
definition. The restriction on the use of PATH-DATA-TLV for SET-
RESPONSE operation is it MUST contain RESULT-TLV(s). The
restriction 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 Section 6.1.1.1.7.
6.6 Query and Query Response Messages 6.6. Query Messages
The ForCES query and query response messages are used by ForCES The ForCES query messages are used by the CE to query LFBs in the FE
elements (CE or FE) to query LFBs in other ForCES element(s) Current for informations like LFB attributes, capabilities, statistics, etc.
version of ForCES protocol limits the use of the messages only for CE Query Messages include the Query Message and the Query Response
to query information of FE. Message.
6.6.1 Query Message 6.6.1. Query Message
As usual, a query message is composed of a common header and a As usual, a query message is composed of a common header and a
message body that consists of one or more TLV data format. Detailed message body that consists of one or more TLV data format. Detailed
description of the message is as below. description of the message is as below.
Message transfer direction: Message transfer direction:
Current version limits the query message transfer direction only
from CE to FE. from CE to FE.
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 SHOULD be set 'ACKAll', meaning a full The ACK flag in the header is always ignored, and a full response
response for a query message is always expected. If the ACK flag for a query message is always expected. The Correlator field in
is set other values, the meaning of the flag will then be the header is set, so that CE can locate the response back from
ignored, and a full response will still be returned by message FE correctly.
receiver.
Message body: Message body:
The query message body consists of (at least) one or more than The query message body MUST consist of at least one LFB select
one TLVs that describe entries to be queried. The TLV is called TLV as described in Section 6.1.1.1.5. The Operation TLV in the
LFBselect TLV and the data format is as below: LFB select TLV is defined below.
Operation TLV for Query:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ | Type = GET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | PATH-DATA-TLV for GET |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17 Figure 22
Operation TLV: Type:
The Operation TLV for the 'Query' message is formatted as: The operation type for query. One operation type is defined:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type = "GET" --- this operation is to request to get LFB
| Type = GET | Length | attributes.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA for GET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 PATH-DATA-TLV for GET:
PATH-DATA for GET: This is generically a PATH-DATA-TLV format that has been defined
This is generically a PATH-DATA format that has been defined in in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF
"Protocol Grammar" section in the PATH-DATA BNF definition, with definition. The restriction on the use of PATH-DATA-TLV for GET
the limitation specifically for GET operation that the PATH-DATA operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV
here will not allow DATARAW-TLV and RESULT-TLV present in the and RESULT-TLV in the data format.
data format, so as to meet the genius of a GET operation.
To better understand the above PDU format, we can show a tree To better illustrate the above PDU format, we show a tree structure
structure for the format as below: for the format as below:
main hdr (type = Query) main hdr (type = Query)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = target LFB class | +-- LFBCLASSID = target LFB class
| | | |
| | | |
| +-- LFBInstance = target LFB instance | +-- LFBInstance = target LFB instance
| | | |
| | | |
| +-- T = operation { GET } | +-- T = operation { GET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | |
| +-- T = operation { GET } | +-- T = operation { GET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | | |
Figure 19 Figure 23
6.6.2 Query Response Message 6.6.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.
A query response message is also composed of a common header and a A query response message is also composed of a common header and a
message body consists of one or more TLVs describing the query message body consists of one or more TLVs describing the query
result. Detailed description of the message is as below. result. Detailed description of the message is as below.
Message transfer direction: Message transfer direction:
Current version limits the query response message transfer from FE to CE.
direction only 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 SHOULD be set 'QueryResponse'. The ACK flag in the header is ignored. As a
'NoACK', meaning no further response for a query response message response itself, the message does not expect a further response
is expected. If the ACK flag is set other values, the meaning of anymore. The Correlator field in the header MUST keep the same
the flag will then be ignored. The Sequence Number in the header as that of the query message to be responded, so that the query
SHOULD keep the same as that of the query message to be message sender can keep track of the response.
responded, so that the query message sender can keep track of the
responses.
Message body: Message body:
The message body for a query response message consists of (at The query response message body MUST consist of at least one LFB
least) one or more than one TLVs that describe query results for select TLV as described in Section 6.1.1.1.5. The Operation TLV
individual queried entries. The TLV is also called LFBselect in the LFB select TLV is defined below.
TLV, and has exactly the same data format as query message,
except the Operation TLV content is different. The order of the Operation TLV for Query Response:
TLV here matches the TLVs in the corresponding Query message, and
the TLV numbers should also keep the same. The Operation TLV
here is a 'GET-RESPONSE' TLV and the data is a 'PATH-DATA'
format for Query Response Data, as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET-RESPOSE | Length | | Type = GET-RESPONSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA for GET-RESPONSE | | PATH-DATA-TLV for GET-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20 Figure 24
PATH-DATA for GET-RESPONSE:
This is generically a PATH-DATA format that has been defined in
"Protocol Grammar" section in the PATH-DATA BNF definition. The
response data will be included in the DATARAW-TLV and/or RESULT-
TLV inside the PATH-DATA format.
6.7 Event Notification and Response Messages
The Event Notification Message is used to allow one ForCES element to Type:
asynchronously notify one or more other ForCES elements in the same The operation type for query response. One operation type is
ForCES NE on events occuring in that ForCES element. The Event defined:
Notification Response Message is used for the receiver of the Event
Notification Message to acknowledge the reception of the event
notification.
Events in current ForCES protocol can be categorized into following Type = "GET-RESPONSE" --- this operation is to response to
types: get operation of LFB attributes.
o Events happened in CE PATH-DATA-TLV for GET-RESPONSE:
This is generically a PATH-DATA-TLV format that has been defined
in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF
definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY
contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the
data encoding. The RESULT-TLV is defined in Section 6.1.1.1.7
and the SPARSEDATA and FULLDATA TLVs are defined in
Section 6.1.1.1.8.
o Events happened in FE 6.7. Event Notification Message
Events can also be categorized into two classes according to whether Event Notification Message is used by FE to asynchronously notify CE
they need subscription or not. An event in one ForCES element that of events that happen in the FE.
needs to be subscribed will send notifications to other ForCES
elements only when the other elements have subscribed to the element
for the event notification. How to subscribe/unsubscribe for an
event is described in the Configure Message section. An event that
does not need to be subscribed will always send notifications to
other ForCES elements when the event happens. Events will be defined
in the ForCES FE model XML definitions for LFBs as attributes; i.e
they will have a path to them that can be used by the config message
to subscribe to.
6.7.1 Event Notification Message All events happen in FE are subscribable by CE. A config message is
used by CE to subscribe/unsubscribe for an event in FE. To subscribe
to an event is usually by specifying to the path of such an event as
described by FE-Model and defined by LFB library.
As usual, an Event Notification Message is composed of a common As usual, an Event Notification Message is composed of a common
header and a message body that consists of one or more TLV data header and a message body that consists of one or more TLV data
format. Detailed description of the message is as below. format. Detailed description of the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE, or CE to FE 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 can MessageType = 'EventNotification'. The ACK flag in the header
be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. MUST be ignored, and the event notification message does not
Note that the 'Success' here only means the receiver of the expect any response from the receiver. The Correlator field in
message has successfully received the message. the header is also ignored because the response is not expected.
Message Body: Message Body:
The message body for an event notification message consists of (at The event notification message body MUST consist of at least one
least) one or more than one TLVs that describe the notified LFB select TLV as described in Section 6.1.1.1.5. The Operation
events. The TLV is defined as follows: TLV in the LFB select TLV is defined below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21
Operation TLV: Operation TLV for Event Notification:
This is a TLV that describes the event to be notified, as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPER = REPORT | Length | | Type = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA for REPORT | | PATH-DATA-TLV for REPORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22 Type:
Only one operation type is defined for the event notification
message:
PATH-DATA for REPORT: Type = "REPORT" --- this type of operation is for FE to
This is generically a PATH-DATA format that has been defined in report something to CE.
"Protocol Grammar" section in the PATH-DATA BNF definition. The
report data will be included in the DATARAW-TLV inside the PATH-
DATA format.
To better understand the above PDU format, we can show a tree PATH-DATA-TLV for REPORT:
structure for the format as below: This is generically a PATH-DATA-TLV format that has been defined
in "Protocol Grammar" section(Section 6.1) in the PATH-DATA BNF
definition. The PATH-DATA-TLV for REPORT operation MAY contain
FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV
in the data format.
To better illustrate the above PDU format, we show a tree structure
for the format as below:
main hdr (type = Event Notification) main hdr (type = Event Notification)
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = target LFB class | +-- LFBCLASSID = target LFB class
| | | |
| | | |
| +-- LFBInstance = target LFB instance | +-- LFBInstance = target LFB instance
| | | |
| | | |
| +-- T = operation { REPORT } | +-- T = operation { REPORT }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | | // 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)
Figure 23
6.7.2 Event Notification Response Message
After sending out an Event Notification Message, the sender may be
interested in ensuring that the message has been received by
receivers, especially when the sender thinks the event notification
is vital for system management. An Event Notification Response
Message is used for this purpose. The ACK flag in the Event
Notification Message header are used to signal if such acknowledge is
requested or not by the sender.
Detailed description of the message is as below:
Message Transfer Direction:
From FE to CE or from CE to FE, just inverse to the direction of
the Event Notification Message that it responses.
Message Header:
The Message Type in the header is set MessageType=
'EventNotificationResponse'. The ACK flag in the header SHOULD be
set 'NoACK', meaning no further response for the message is
expected. If the ACK flag is set other values, the meaning of the
flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the message to be responded, so
that the event notificatin message sender can keep track of the
responses.
Message Body:
The message body for an event notification response message
consists of (at least) one or more than one TLVs that describe the
notified events. The TLV is also called LFBselect TLV, and has
exactly the same data format as Event Notification Message, except
the Operation TLV inside is different. The order of the TLV here
matches the TLVs in the corresponding Event Message, and the TLV
numbers should keep the same. The Operation TLV here is a
'REPORT-RESPONSE' TLV and the data is a 'PATH-DATA' format for
event response data, as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT-RESPONSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PATH-DATA for REPORT-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24
PATH-DATA for REPORT-RESPONSE: Figure 26
This is generically a PATH-DATA format that has been defined in
"Protocol Grammar" section in the PATH-DATA BNF definition. The
response data will be included in the RESULT-TLV inside the PATH-
DATA format.
6.8 Packet Redirect Message 6.8. Packet Redirect Message
Packet redirect message is used to transfer data packets between CE Packet redirect message is used to transfer data packets between CE
and FE. Usually these data packets are IP packets, though they may and FE. Usually these data packets are IP packets, though they may
sometimes associated with some metadata generated by other LFBs in sometimes associated with some metadata generated by other LFBs in
the model, or they may occasionally be other protocol packets, which the model, or they may occasionally be other protocol packets, which
usually happen when CE and FE are jointly implementing some high- usually happen when CE and FE are jointly implementing some high-
touch operations. Packets redirected from FE to CE are the data touch operations. Packets redirected from FE to CE are the data
packets that come from forwarding plane, and usually are the data packets that come from forwarding plane, and usually are the data
packets that need high-touch operations in CE,or packets for which packets that need high-touch operations in CE,or packets for which
the IP destination address is the NE. Packets redirected from CE to the IP destination address is the NE. Packets redirected from CE to
skipping to change at page 55, line 22 skipping to change at page 59, line 14
is duplicated and one is redirected to CE and the other continues its is duplicated and one is redirected to CE and the other continues its
way in the LFB topology. way in the LFB topology.
The Packet Redirect Message data format is formated as follows: The Packet Redirect Message data format is formated as follows:
Message Direction: Message Direction:
CE to FE or FE to CE CE to FE or 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=
'PacketRedirect'. The ACK flags in the header SHOULD be set 'PacketRedirect'. The ACK flags in the header MUST be ignored,
'NoACK', meaning no response is expected by this message. If the and no response is expected by this message. The correlator field
ACK flag is set other values, the meanings will be ignored. is also ignored because no response is expected.
Message Body: Message Body:
Consists of one or more TLVs, with every TLV having the following Consists of (at least) one or more than one TLV that describes the
data format: packet redirection. The TLV is specifically a Redirect TLV (with
the TLV Type="Redirect"). Detailed data format of a Redirect TLV
for packet redirect message is as below:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data TLV | | Meta Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirect Data TLV | | Redirect Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25 Figure 27
LFB class ID: LFB class ID:
There are only two possible LFB classes here, the 'RedirectSink' There are only two possible LFB classes here, the 'RedirectSink'
LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from
FE to CE, the LFB class should be 'RedirectSink'. If the message FE to CE, the LFB class should be 'RedirectSink'. If the message
is from CE to FE, the LFB class should be 'RedirectSource'. is from CE to FE, the LFB class should be 'RedirectSource'.
Instance ID: Instance ID:
Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB.
Meta Data TLV: Meta Data TLV:
skipping to change at page 56, line 29 skipping to change at page 60, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV | | Meta Data ILV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26 Figure 28
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ID | | Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value | | Meta Data Value |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
usually defined by FE-Model[FE-MODEL]. statically assigned by the LFB definition. This actually implies
a Meta Data ID transcoding mechanism may be necessary if a
metadata traverses several LFBs while these LFBs define the
metadata with different Meta Data IDs.
Usually there are two meta data that are necessary for CE-FE Usually there are two meta data that are necessary for CE-FE
redirect operation. One is the redirected data type (e.g., IP redirect operation. One is the redirected data type (e.g., IP
packet, TCP packet, or UDP Packet). For an FE->CE redirect packet, TCP packet, or UDP Packet). For an FE->CE redirect
operation, redirected packet type meta data is usually a meta data operation, redirected packet type meta data is usually a meta data
specified by a Classifier LFB that filter out redirected packets specified by a Classifier LFB that filter out redirected packets
from packet stream and sends the packets to Redirect Sink LFB. from packet stream and sends the packets to Redirect Sink LFB.
For an CE->FE redirect operation, the redirected packet type meta For an CE->FE redirect operation, the redirected packet type meta
data is usually directly generated by CE. data is usually directly generated by CE.
skipping to change at page 57, line 31 skipping to change at page 61, line 25
| Type = REDIRECTDATA | Length | | Type = REDIRECTDATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data | | Redirected Data |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirected Data: Redirected Data:
This field presents the whole packet that is to be redirected. This field presents the whole packet that is to be redirected.
The packet should be 32bits aligned. The packet should be 32bits aligned.
6.9 Heartbeat Message 6.9. 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. same ForCES NE on its liveness.
A Heartbeat Message is sent by a ForCES element periodically. The A Heartbeat Message is sent by a ForCES element periodically. The
time interval to send the message is set by the Association Setup parameterization and policy definition for heartbeats for an FE is
Message described in Section 6.1.1. A little different from other managed as attributes of the FE protocol LFB, and can be set by CE
protocol messages, a Heartbeat message is only composed of a common via a config message. The Heartbeat message is a little different
header, withe the message body left empty. Detailed description of from other protocol messages in that it is only composed of a common
header, with the message body left empty. Detailed description of
the message is as below. the message is as below.
Message Transfer Direction: Message Transfer Direction:
FE to CE, or CE to FE FE to CE, or CE to FE
Message Header: Message Header:
The Message Type in the message header is set to MessageType = The Message Type in the message header is set to MessageType =
'Heartbeat'. The ACK flag in the header SHOULD be set to 'Heartbeat'. Section 3.3.2 describes the HB mechanisms used.
'NoACK', meaning no response from receiver(s) is expected by the The ACK flag in the header can be set to 'NoACK' or 'AlwaysACK'
message sender. Other values of the ACK flag will always be when the HB is sent. When set to 'AlwaysACK', the HB Message
ignored by the message receiver. sender is always expecting a response from its receiver. When a
response is sent it is always an echo of the original message
with reversed IDs and the ACK information set to 'NoACK'. When
not soliciting for response(default behavior), the ACK flag is
set to 'NoACK' The correlator field in the HB message header must
be set accordingly when a response is expected so that a receiver
can correlate the response correctly. The correlator field can
be ignored if no response is expected. Also note that by virtue
of Heartbeat policies defined in Section 6.2.1 only CE can send a
HB Message with a response request.
Message Body: Message Body:
The message body is empty for the Heartbeat Message. The message body is empty for the Heartbeat Message.
6.10 Operation Summary 6.10. Operation Summary
The following tables summarize the operations and their applicabiity
to the messages.
No Operations for the following messages:
Assoc-Setup
Assoc-Setup-Resp The following table summarizes the TLVs that compose messages, and
the applicabiity of operation TLVs to the messages.
Assoc-Teardown +---------------------------+-----------+---------------------------+
| Messages | TLVs | Operations |
+---------------------------+-----------+---------------------------+
| Association Setup | LFBselect | REPORT |
| | | |
| Association Setup | ASRresult | None |
| Response | | |
| | | |
| Association Teardown | ASTreason | None |
| | | |
| Config | LFBselect | SET, DEL |
| | | |
| Config Response | LFBselect | SET-RESPONSE, |
| | | DEL-RESPONSE |
| | | |
| Query | LFBselect | GET |
| | | |
| Query Response | LFBselect | GET-RESPONSE |
| | | |
| Event Notification | LFBselect | REPORT |
| | | |
| Packet Redirect | Redirect | None |
| | | |
| Heartbeat | None | None |
+---------------------------+-----------+---------------------------+
Heartbeat The following talbe summarises the applicability of the FULL/SPARSE
DATA TLV and the RESULT TLV to the Operation TLVs.
+-------------------+-------+------------+--------+-------------+ +--------------+--------------+----------------+------------+
| Operation | Query | Query-Resp | Config | config-Resp | | Operations | FULLDATA TLV | SPARSEDATA TLV | RESULT TLV |
+-------------------+-------+------------+--------+-------------+ +--------------+--------------+----------------+------------+
| Set | | | X | X | | SET | MAY | MAY | MUST NOT |
| | | | | |
| Delete | | | X | X |
| | | | | |
| Update | | | X | X |
| | | | | |
| Get | X | X | | |
| | | | | |
| Event subscribe | | | X | X |
| | | | | |
| Event unsubscribe | | | X | X |
+-------------------+-------+------------+--------+-------------+
+-----------+--------------+-------------+------------------+
| Operation | Packet-Redir | Event-Notif | Event-Notif-Resp |
+-----------+--------------+-------------+------------------+
| Payload | X | | |
| | | | | | | | | |
| Report | | X | X | | SET-RESPONSE | MAY | MUST NOT | MUST |
+-----------+--------------+-------------+------------------+ | | | | |
| DEL | MAY | MAY | MUST NOT |
| | | | |
| DEL-RESPONSE | MAY | MUST NOT | MUST |
| | | | |
| GET | MUST NOT | MUST NOT | MUST NOT |
| | | | |
| GET-RESPONSE | MUST | MUST NOT | MAY |
| | | | |
| REPORT | MAY | MUST NOT | MUST NOT |
+--------------+--------------+----------------+------------+
7. Protocol Scenarios 7. Protocol Scenarios
7.1 Association Setup state 7.1. Association Setup state
The associations among CEs and FEs are initiated via Association The associations among CEs and FEs are initiated via Association
setup message from the FE. If a setup request is granted by the CE, setup message from the FE. If a setup request is granted by the CE,
a successful setup response message is sent to the FE. If CEs and a successful setup response message is sent to the FE. If CEs and
FEs are operating in an insecure environment then the security FEs are operating in an insecure environment then the security
association have to be established between them before any association have to be established between them before any
association messages can be exchanged. The TML will take care of association messages can be exchanged. The TML will take care of
establishing any security associations. establishing any security associations.
This is followed by capability query, topology query. When the FE is This is typically followed by capability query, topology query, etc.
ready to start forwarding data traffic, it sends a FE UP Event When the FE is ready to start forwarding data traffic, it sends a FE
message to the CE. The CE responds with a FE ACTIVATE State UP Event message to the CE. When the CE is ready, it by enabling the
Maintenance message to ask the FE to go active and start forwarding FE by setting the FEStatus to Adminup [Refer to Model draft for
data traffic. At this point the association establishment is details]. This indicates to the FE to start forwarding data traffic.
complete. These sequences of messages are illustrated in the Figure At this point the association establishment is complete. These
below. sequences of messages are illustrated in the Figure below.
FE PL CE PL FE PL CE PL
| | | |
| Asso Setup Req | | Asso Setup Req |
|---------------------->| |---------------------->|
| | | |
| Asso Setup Resp | | Asso Setup Resp |
|<----------------------| |<----------------------|
| | | |
| Capability Query | | LFBx Query capability |
|<----------------------| |<----------------------|
| | | |
| Query Resp | | LFBx Query Resp |
|---------------------->| |---------------------->|
| | | |
| Topo Query | | FEO Query (Topology) |
|<----------------------| |<----------------------|
| | | |
| Topo Query Resp | | FEO Query Resp |
|---------------------->| |---------------------->|
| | | |
| FE UP Event | | Config FEO Adminup |
|<----------------------|
| |
| FEO Config-Resp |
|---------------------->| |---------------------->|
| | | |
| Config-Activate FE | | FEO UP Event |
|<----------------------| |---------------------->|
| | | |
Figure 29: Message exchange between CE and FE to establish an NE Figure 31: Message exchange between CE and FE to establish an NE
association association
On successful completion of this state, the FE joins the NE and is On successful completion of this state, the FE joins the NE.
moved to the Established State or Steady state.
7.2 Association Established state or Steady State 7.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 continously updated or queried. The FE may
also send asynchronous event notifications to the CE or synchronous also send asynchronous event notifications to the CE or synchronous
heartbeat messages. This continues until a termination (or heartbeat messages. This continues until a termination (or
deactivation) is initiated by either the CE or FE. Figure below deactivation) is initiated by either the CE or FE. Figure below
helps illustrate this state. helps illustrate this state.
FE PL CE PL FE PL CE PL
| | | |
| Heart Beat | | Heart Beat |
|<----------------------| |<---------------------------->|
| | | |
| Heart Beat | | Heart Beat |
|---------------------->| |----------------------------->|
| | | |
| Config-Subscribe Ev | | Config-set LFBy (Event sub.) |
|<----------------------| |<-----------------------------|
| | | |
| Config Resp | | Config Resp LFBy |
|---------------------->| |----------------------------->|
| | | |
| Config-Add LFB Attr | | Config-set LFBx Attr |
|<----------------------| |<-----------------------------|
| | | |
| Config Resp | | Config Resp LFBx |
|---------------------->| |----------------------------->|
| | | |
| Query LFB Stats | |Config-Query LFBz (Stats) |
|<----------------------| |<--------------------------- -|
| | | |
| Query Resp | | Query Resp LFBz |
|---------------------->| |----------------------------->|
| | | |
| FE Event Report | | FE Event Report |
|---------------------->| |----------------------------->|
| | | |
| Config-Del LFB Attr | | Config-Del LFBx Attr |
|<----------------------| |<-----------------------------|
| | | |
| Config Resp | | Config Resp LFBx |
|---------------------->| |----------------------------->|
| | | |
| Packet Redirect | | Packet Redirect LFBx |
|---------------------->| |----------------------------->|
| | | |
| Heart Beat | | Heart Beat |
|<----------------------| |<-----------------------------|
. . . .
. . . .
| | | |
| Config-Activate FE |
|<----------------------|
| |
Figure 30: Message exchange between CE and FE during steady-state
communication
Figure 32: Message exchange between CE and FE during steady-state
communication
Note that the sequence of messages shown in the figure serve only as Note that the sequence of messages shown in the figure serve only as
examples and the messages exchange sequences could be different from examples and the messages exchange sequences could be different from
what is shown in the figure. Also, note that the protocol scenarios what is shown in the figure. Also, note that the protocol scenarios
described in this section do not include all the different message described in this section do not include all the different message
exchanges which would take place during failover. That is described exchanges which would take place during failover. That is described
in the HA section 8. in the HA section 8.
8. High Availability Support 8. High Availability Support
The ForCES protocol provides mechanisms for CE redundancy and The ForCES protocol provides mechanisms for CE redundancy and
failover, in order to support High Availability as defined in failover, in order to support High Availability as defined in
[RFC3654]. FE redundancy and FE to FE interaction is currently out [RFC3654]. FE redundancy and FE to FE interaction is currently out
of scope of this draft. There can be multiple redundant CEs and FEs of scope of this draft. There can be multiple redundant CEs and FEs
in a ForCES NE. However, at any time there can only be one Primary in a ForCES NE. However, at any time there can only be one Primary
CE controlling the FEs and there can be multiple secondary CEs. The CE controlling the FEs and there can be multiple secondary CEs. The
FE and the CE PL are aware of the primary and secondary CEs. This FE and the CE PL are aware of the primary and secondary CEs. This
information (primary, secondary CEs) is configured in the FE, CE PLs information (primary, secondary CEs) is configured in the FE, CE PLs
during pre-association by FEM, CEM respectively. Only the primary CE during pre-association by FEM, CEM respectively. Only the primary CE
sends Control messages to the FEs. The FE may send its event sends Control messages to the FEs.
reports, redirection packets to only the Primary CE (Report Primary
Mode) or it may send these to both primary and secondary CEs (Report There are 2 modes of HA defined in the ForCES protocol, Report
All Mode). (The latter helps with keeping state between CEs Primary Mode and Report All Mode. The Report Primary Mode is the
synchronized, although it does not guarantee synchronization.) This default mode of the protocol, in which the FEs only associate with
behavior or HA Modes are configured during Association setup phase one CE (primary) at a time. The Report All mode is for future study
but can be changed by the CE anytime during protocol operation. A and not part of the current protocol version. In this mode, the FE
CE-to-CE synchronization protocol will be needed in most cases to would establish association with multiple CEs (primary and secondary)
support fast failover, however this will not be defined by the ForCES and report events, packets, Heart Beats to all the CEs. However,
protocol. only the primary CE would configure/control the FE in this mode as
well. This helps with keeping state between CEs synchronized,
although it does not guarantee synchronization.
The HA Modes are configured during Association setup phase, currently
only Report Primary Mode is configured. A CE-to-CE synchronization
protocol will be needed to support fast failover as well as address
some of the corner cases, however this will not be defined by the
ForCES protocol (since it is out of scope).
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), the TML on the FE due to CE or link reasons, i.e. not FE related), the TML on the FE
will trigger the FE PL regarding this failure. This can also be will trigger the FE PL regarding this failure. This can also be
detected using the HB messages between FEs and CEs. The FE PL will detected using the HB messages between FEs and CEs. The
send a message (Event Report) to the Secondary CEs to indicate this communication failure (detected via either of the two means described
failure or the CE PL will detect this and one of the Secondary CEs before) is considered as a loss of association between the CE and
takes over as the primary CE for the FE. During this phase, if the corresponding FE and the FE PL must establish association with the
original primary CE comes alive and starts sending any commands to secondary CE at this point. During this phase, if the original
the FE, the FE should ignore those messages and send an Event to all primary CE comes alive and starts sending any commands to the FE, the
CEs indicating its change in Primary CE. Thus the FE only has one FE should ignore those messages and send an Event to all CEs
indicating its change in Primary CE. Thus the FE only has one
primary CE at a time. primary CE at a time.
An explicit message (Config message- Move command) from the primary An explicit message (Config message setting Primary CE attribute in
CE, can also be used to change the Primary CE for an FE during normal ForCES Protocol object) from the primary CE, can also be used to
protocol operation. In order to support fast failover, the FE will change the Primary CE for an FE during normal protocol operation.
establish association (setup msg) as well as complete the capability
exchange with the Primary as well as all the Secondary CEs (in all Also note that the FEs in a ForCES NE could also use a multicast
scenarios/modes). CEID, i.e. they are associated with a group of CEs (assumes some form
of CE-CE synchronization protocol). In this case the loss of
association would mean that communication with the entire multicast
group of CEs has been lost. The mechanisms described above will
apply for this case as well during the loss of association.
These two scenarios (Report All, Report Primary) have been These two scenarios (Report All, Report Primary) have been
illustrated in the figures below. illustrated in the figures below.
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| Asso Estb,Caps|exchange | | Asso Estb,Caps|exchange |
skipping to change at page 65, line 30 skipping to change at page 69, line 37
4 |-----------------------|------------------->| 4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 5 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |------------------------------------------->| 6 |------------------------------------------->|
Figure 31: CE Failover for Report All mode Figure 33: CE Failover for Report All mode
FE CE Primary CE Secondary FE CE Primary CE Secondary
| | | | | |
| Asso Estb,Caps exchg | | | Asso Estb,Caps exchg | |
1 |<--------------------->| | 1 |<--------------------->| |
| | | | | |
| Asso Estb,Caps|exchange |
2 |<----------------------|------------------->|
| | |
| All msgs | | | All msgs | |
3 |<--------------------->| | 2 |<--------------------->| |
| | | | | |
| (HeartBeats| only) |
4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Asso Estb,Caps exchange |
3 |<------------------------------------------>|
| |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 4 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |------------------------------------------->| 5 |------------------------------------------->|
Figure 32: CE Failover for Report Primary Mode Figure 34: CE Failover for Report Primary Mode
8.1 Responsibilities for HA 8.1. Responsibilities for HA
TML level - Transport level: TML level - Transport level:
1. The TML controls logical connection availability and failover. 1. The TML controls logical connection availability and failover.
2. The TML also controls peer HA managements. 2. The TML also controls peer HA managements.
At this level, control of all lower layers, for example transport At this level, control of all lower layers, for example transport
level (such as IP addresses, MAC addresses etc) and associated links level (such as IP addresses, MAC addresses etc) and associated links
going down are the role of the TML. going down are the role of the TML.
skipping to change at page 68, line 7 skipping to change at page 71, line 7
primary CE (config - move), and other HA related operations described primary CE (config - move), and other HA related operations described
before are the PL responsibility. before are the PL responsibility.
To put the two together, if a path to a primary CE is down, the TML To put the two together, if a path to a primary CE is down, the TML
would take care of failing over to a backup path, if one is would take care of failing over to a backup path, if one is
available. If the CE is totally unreachable then the PL would be available. If the CE is totally unreachable then the PL would be
informed and it will take the appropriate actions described before. informed and it will take the appropriate actions described before.
9. Security Considerations 9. Security Considerations
ForCES architecture identified several [Reference Arch] levels of ForCES architecture identifies several levels of security in
security. ForCES PL uses security services provided by the ForCES [RFC3746]. ForCES PL uses security services provided by the ForCES
TML layer. TML layer provides security services such as endpoint TML layer. TML layer provides security services such as endpoint
authentication service, message authentication service and authentication service, message authentication service and
confidentiality service. Endpoint authentication service is invoked confidentiality service. Endpoint authentication service is invoked
at the time of pre-association connection establishment phase and at the time of pre-association connection establishment phase and
message authentication is performed whenever FE or CE receives a message authentication is performed whenever FE or CE receives a
packet from its peer. packet from its peer.
Following are the general security mechanism that needs to be in Following are the general security mechanism that needs to be in
place for ForCES PL layer. place for ForCES PL layer.
skipping to change at page 68, line 33 skipping to change at page 71, line 33
o Operator should configure the same security policies for both o Operator should configure the same security policies for both
primary and backup FE's and CE's (if available). This will ensure primary and backup FE's and CE's (if available). This will ensure
uniform operations, and to avoid unnecessary complexity in policy uniform operations, and to avoid unnecessary complexity in policy
configuration. configuration.
o ForCES PL endpoints SHOULD pre-established connections with both o ForCES PL endpoints SHOULD pre-established connections with both
primary and backup CE's. This will reduce the security messages primary and backup CE's. This will reduce the security messages
and enable rapid switchover operations for HA. and enable rapid switchover operations for HA.
9.1 No Security 9.1. No Security
When No security is chosen for ForCES protocol communication, both When No security is chosen for ForCES protocol communication, both
endpoint authentication and message authentication service needs be endpoint authentication and message authentication service needs be
performed by ForCES PL layer. Both these mechanism are weak and does performed by ForCES PL layer. Both these mechanism are weak and does
not involve cryptographic operation. Operator can choose "No not involve cryptographic operation. Operator can choose "No
security" level when the ForCES protocol endpoints are within an security" level when the ForCES protocol endpoints are within an
single box. single box.
In order to have interoperable and uniform implementation across In order to have interoperable and uniform implementation across
various security levels, each CE and FE endpoint MUST implement this various security levels, each CE and FE endpoint MUST implement this
level. The operations that are being performed for "No security" level. The operations that are being performed for "No security"
level is required even if lower TML security services are being used. level is required even if lower TML security services are being used.
9.1.1 Endpoint Authentication 9.1.1. Endpoint Authentication
Each CE and FE PL layer maintain set of associations list as part of Each CE and FE PL layer maintain set of associations list as part of
configuration. This is done via CEM and FEM interfaces. FE MUST configuration. This is done via CEM and FEM interfaces. FE MUST
connect to only those CE's that are configured via FEM similarly CE connect to only those CE's that are configured via FEM similarly CE
should accept the connection and establish associations for the FE's should accept the connection and establish associations for the FE's
which are configured via CEM. CE should validate the FE identifier which are configured via CEM. CE should validate the FE identifier
before accepting the connection during the pre-association phase. before accepting the connection during the pre-association phase.
9.1.2 Message authentication 9.1.2. Message authentication
When CE or FE generates initiates a message, the receiving endpoint When CE or FE generates initiates a message, the receiving endpoint
MUST validate the initiator of the message by checking the common MUST validate the initiator of the message by checking the common
header CE or FE identifiers. This will ensure proper protocol header CE or FE identifiers. This will ensure proper protocol
functioning. We recommend this extra step processing even if the functioning. We recommend this extra step processing even if the
underlying TLM layer security services. underlying TLM layer security services.
9.2 ForCES PL and TML security service 9.2. ForCES PL and TML security service
This section is applicable if operator wishes to use the TML security This section is applicable if operator wishes to use the TML security
services. ForCES TML layer MUST support one or more security service services. ForCES TML layer MUST support one or more security service
such as endpoint authentication service, message authentication such as endpoint authentication service, message authentication
service, confidentiality service as part of TML security layer service, confidentiality service as part of TML security layer
functions. It is the responsibility of the operator to select functions. It is the responsibility of the operator to select
appropriate security service and configure security policies appropriate security service and configure security policies
accordingly. The details of such configuration is outside the scope accordingly. The details of such configuration is outside the scope
of ForCES PL and is depending upon the type of transport protocol, of ForCES PL and is depending upon the type of transport protocol,
nature of connection. nature of connection.
All these configurations should be done prior to starting the CE and All these configurations should be done prior to starting the CE and
FE. FE.
When certificates-based authentication is being used at TML layer, When certificates-based authentication is being used at TML layer,
the certificate can use ForCES specific naming structure as the certificate can use ForCES specific naming structure as
certificate names and accordingly the security policies can be certificate names and accordingly the security policies can be
configured at CE and FE. configured at CE and FE.
9.2.1 Endpoint authentication service 9.2.1. Endpoint authentication service
When TML security services are enabled. ForCES TML layer performs When TML security services are enabled. ForCES TML layer performs
endpoint authentication. Security association is established between endpoint authentication. Security association is established between
CE and FE and is transparent to the ForCES PL layer. CE and FE and is transparent to the ForCES PL layer.
We recommend that FE after establishing the connection with the We recommend that FE after establishing the connection with the
primary CE, should establish the security association with the backup primary CE, should establish the security association with the backup
CE (if available). During the switchover operation CE's security CE (if available). During the switchover operation CE's security
state associated with each SA's are not transferred. SA between state associated with each SA's are not transferred. SA between
primary CE and FE and backup CE and FE are treated as two separate primary CE and FE and backup CE and FE are treated as two separate
SA's. SA's.
9.2.2 Message authentication service 9.2.2. Message authentication service
This is TML specific operation and is transparent to ForCES PL This is TML specific operation and is transparent to ForCES PL layer.
layer[TML document]. For details refer to Section 4.
9.2.3 Confidentiality service 9.2.3. Confidentiality service
This is TML specific operation and is transparent to ForCES PL This is TML specific operation and is transparent to ForCES PL layer.
layer.[TML document] For details refer to Section 4.
10. Acknowledgments 10. Acknowledgments
The authors of this draft would like to acknowledge and thank the The authors of this draft would like to acknowledge and thank the
following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes, following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes,
Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering,
Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for
their contributions. We would also like to thank David Putzolu, and their contributions. We would also like to thank David Putzolu, and
Patrick Droz for their comments and suggestions on the protocol. Patrick Droz for their comments and suggestions on the protocol.
11. References 11. References
11.1 Normative References 11.1. Normative References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003. of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES) "Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004. Framework", RFC 3746, April 2004.
11.2 Informational References 11.2. Informational References
[2PCREF] Gray, J., "Notes on database operating systems. In
Operating Systems: An Advanced Course. Lecture Notes in
Computer Science, Vol. 60, pp. 394-481, Springer-Verlag",
1978.
[ACID] Haerder, T. and A. Reuter, "Principles of Transaction- [ACID] Haerder, T. and A. Reuter, "Principles of Transaction-
Orientated Database Recovery", 1983. Orientated Database Recovery", 1983.
[FE-MODEL] [FE-MODEL]
Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,
and S. Blake, "ForCES Forwarding Element Model", and S. Blake, "ForCES Forwarding Element Model",
Feb. 2005. Feb. 2005.
Author's Address Appendix A. Authors' Addresses
Avri Doria
ETRI
Lulea University of Technology
Lulea
Sweden
Phone: +1 401 663 5024
Email: avri@acm.org
Appendix A. Individual Authors/Editors Contact
Ligang Dong Ligang Dong
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
P.R.China P.R.China
Phone: +86-571-88071024 Phone: +86-571-88071024
EMail: donglg@mail.hzic.edu.cn EMail: donglg@mail.zjgsu.edu.cn
Avri Doria Avri Doria
ETRI ETRI
EMail: avri@acm.org EMail: avri@acm.org
Ram Gopal Ram Gopal
Nokia Nokia
5, Wayside Road 5, Wayside Road
Burlington MA 01803 Burlington MA 01803
USA USA
skipping to change at page 74, line 9 skipping to change at page 77, line 9
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 Hillsboro, OR 97124
USA USA
Phone: +1 503 264 0334 Phone: +1 503 264 0334
EMail: hormuzd.m.khosravi@intel.com EMail: hormuzd.m.khosravi@intel.com
Weiming Wang Weiming Wang
Zhejiang Gongshang University Zhejiang Gongshang University
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
P.R.China P.R.China
Phone: +86-571-88057712 Phone: +86-571-88071024
EMail: wmwang@mail.hzic.edu.cn EMail: wmwang@mail.zjgsu.edu.cn
Appendix B. IANA considerations Appendix B. IANA Considerations
tbd Following the policies outlined in "Guidelines for Writing an IANA
Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following
name spaces are defined in ForCES.
o Message Type Name Space (add xref)
o Header Flags (add xref)
o TLV Type (add xref)
o Result TLV value (add xref)
o LFB Class ID (add xref)
o Result: Association Setup Repsonse (add xref)
o Reason: Association Teardown Message (add xref)
o Operation type (add xref)
o Configuration Request: Operation Result (add xref)
B.1. Message Type Name Space
The Message Type is an 8 bit value. The following is the guideline
for defining the Message Type namespace
Message Types 0x00 - 0x0F
Message Types in this range are part of the base ForCES Protocol.
Message Types in this range are allocated through an IETF
consensus action. [RFC2434]
Values assigned by this specification:
0x00 ............... Heartbeat
0x01 ............... Association Messages
0x02 ............... Configuration Messages
0x03 ............... Query Messages
0x04 ............... Event Notifications
0x05 ............... Packet Redirection
Message Types 0x10 - 0x7F
Message Types in this range are Specification Required [RFC2434]
Message Types using this range must be documented in an RFC or
other permanent and readily available references.
Message Types 0x80 - 0xFF
Message Types in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA
management of this range of the Message Type Name Space is
unnecessary.
B.2. Operation Type
The Operation Type name space is 16 bits long. The following is the
guideline for managing the Operation Type Name Space.
Operation Type 0x0000-0x00FF
Operation Types in this range are allocated through an IETF
consensus process. [RFC2434].
Values assigned by this specification:
0x0000 Reserved
0x0001 ADD
Operation Type 0x0100-0x7FFF
Operation Types using this range must be documented in an RFC or
other permanent and readily available references. [RFC2434].
Operation Type 0x8000-0xFFFF
Operation Types in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA
management of this range of the Operation Type Name Space is
unnecessary.
B.3. Header Flags
The Header flag field is 32 bits long Header flags are part of the
ForCES base protocol. Header flags are allocated through an IETF
consensus action [RFC2434]. TLV Result Values in this range are
allocated through an IETF consensus process. [RFC2434].
Values assigned by this specification:
B.4. LFB Class Id Name Space
TheLFB Class ID name space is 32 bits long. The following iws the
guideline for managing the TLV Result Name Space.
LFB Class ID 0x00000000-0x0000FFFF
LFB Class IDs in this range are allocated through an IETF
consensus process. [RFC2434].
Values assigned by this specification:
0x00000000 Reserved
0x00000001 FE Protocol LFB
0x00000002 FE LFB
LFB Class ID 0x00010000-0x7FFFFFFF
LFB Class IDs in this range are Specification Required [RFC2434]
LFB Class ID using this range must be documented in an RFC or
other permanent and readily available references. [RFC2434].
LFB Class Id 0x80000000-0xFFFFFFFFF
LFB Class IDs in this range are reserved for vendor private
extensions and are the responsibility of individual vendors. IANA
management of this range of the LFB Class ID Space is unnecessary.
B.5. Association Setup Repsonse
The Association Setup Repsonse name space is 16 bits long. The
following is the guideline for managing the Association Setup
Repsonse Name Space.
Association Setup Repsonse 0x0000-0x00FF
Association Setup Repsonses in this range are allocated through an
IETF consensus process. [RFC2434].
Values assigned by this specification:
0x0000 Succcess
0x0001 FE ID Invalid
0x0002 Too many associations
0x0003 Permission Denied
Association Setup Repsonse 0x0100-0x0FFF
Association Setup Repsonses in this range are Specification
Required [RFC2434] Values using this range must be documented in
an RFC or other permanent and readily available references.
[RFC2434].
Association Setup Repsonse 0x80000000-0xFFFFFFFFF
Association Setup Repsonses in this range are reserved for vendor
private extensions and are the responsibility of individual
vendors. IANA management of this range of the Association Setup
Repsonses Name Space is unnecessary.
B.6. Association Teardown Message
The Association Teardown Message name space is 32 bits long. The
following is the guideline for managing the TLV Result Name Space.
Association Teardown Message 0x00000000-0x0000FFFF
Association Teardown Messages in this range are allocated through
an IETF consensus process. [RFC2434].
Values assigned by this specification:
0x00000000 Normal - Teardown by Administrator
0x00000001 Error - Out of Memory
0x00000002 Error - Application Crash
0x000000FF Error - Unspecified
Association Teardown Message 0x00010000-0x7FFFFFFF
Association Teardown Messages in this range are Specification
Required [RFC2434] Association Teardown Messages using this range
must be documented in an RFC or other permanent and readily
available references. [RFC2434].
LFB Class Id 0x80000000-0xFFFFFFFFF
Association Teardown Messages in this range are reserved for
vendor private extensions and are the responsibility of individual
vendors. IANA management of this range of the Association
Teardown Message Name Space is unnecessary.
B.7. Configuration Request Result
The Configuration Request name space is 32 bits long. The following
is the guideline for managing the Configuration Request Name Space.
Configuration Request 0x0000-0x00FF
Configuration Requests in this range are allocated through an IETF
consensus process. [RFC2434].
Values assigned by this specification:
0x0000 Success
0x0001 FE ID Invalid
0x0003 Permission Denied
Configuration Request 0x0100-0x7FFF
Configuration Requests in this range are Specification Required
[RFC2434] Configuration Requests using this range must be
documented in an RFC or other permanent and readily available
references. [RFC2434].
0x8000-0xFFFF
Configuration Requests in this range are reserved for vendor
private extensions and are the responsibility of individual
vendors. IANA management of this range of the Configuration
Request Name Space is unnecessary.
Appendix C. Forces Protocol LFB schema Appendix C. Forces Protocol LFB schema
The schema described below conforms to the LFB schema (language?) The schema described below conforms to the LFB schema (language?)
described in Forces Model draft[FE-MODEL] described in Forces Model draft[FE-MODEL]
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel" <LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation= xsi:schemaLocation=
"http://ietf.org/forces/1.0/lfbmodel "http://ietf.org/forces/1.0/lfbmodel
file:/home/hadi/xmlj1/lfbmodel.xsd" provides="FEPO"> file:/home/hadi/xmlj1/lfbmodel.xsd" provides="FEPO">
<!-- XXX --> <!-- XXX -->
<dataTypeDefs>
<dataTypeDef>
<name>CEHBPolicyValues</name>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEHBPolicy0</name>
<synopsis>
The CE heartbeat policy 0, refer to RFC
xxxx (ForCES protocol specification) Section
6.2.1 for details
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEHBPolicy1</name>
<synopsis>
The CE heartbeat policy 1, refer to RFC xxxx
Section 6.2.1 for details </synopsis>
<synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FEHBPolicyValues</name>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FEHBPolicy0</name>
<synopsis>
The FE heartbeat policy 0, refer to RFCxxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE heartbeat policy 1, refer to RFC xxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restart policy 0, refer to RFCxxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
<specialValue value="1">
<name>FERestartPolicy1</name>
<synopsis>
The FE restart policy 1, refer to RFC xxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The CE failover policy 0, refer to RFCxxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The CE failover policy 1, refer to RFC xxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
<specialValue value="2">
<name>CEFailoverPolicy2</name>
<synopsis>
The CE failover policy 2, refer to RFC xxxx
Section 6.2.1 for details
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef> <LFBClassDef>
<name>FEPO</name> <name>FEPO</name>
<id>1</id> <id>1</id>
<synopsis> <synopsis>
The FE Protocol Object The FE Protocol Object
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<derivedFrom>baseclass</derivedFrom> <derivedFrom>baseclass</derivedFrom>
<events>
<attribute>
<name>HBstate</name>
<id>2</id>
<synopsis>
Heartbeat event status(yes/no)
</synopsis>
<typeRef>boolean</typeRef>
</attribute>
</events>
<capabilities> <capabilities>
<capability> <capability elementID="30" access="read-only">
<name>SupportableVersions</name> <name>SupportableVersions</name>
<id>1</id>
<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>
</capabilities> </capabilities>
<attributes> <attributes>
<attribute access="read-write"> <attribute elementID="1" access="read-only">
<name>HBI</name> <name>CurrentRunningVersion</name>
<id>3</id> <synopsis>Currently running ForCES version</synopsis>
<synopsis>Heartbeat Interval in millisecs</synopsis> <typeRef>u8</typeRef>
</attribute>
<attribute elementID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </attribute>
<attribute access="read-write"> <attribute elementID="3" access="read-write">
<name>HBDI</name> <name>MulticastFEIDs</name>
<id>4</id> <synopsis>
<synopsis>Heartbeat Dead Interval in millisecs</synopsis> the table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</array>
</attribute> </attribute>
<attribute access="read-only"> <attribute elementID="4" access="read-write">
<name>CurrentRunningVersion</name> <name>CEHBPolicy</name>
<id>5</id> <synopsis>
<synopsis>Currently running ForCES version</synopsis> The CE Heartbeat Policy</synopsis>
<typeRef>u8</typeRef> </synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</attribute>
<attribute elementID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in millisecs</synopsis>
</synopsis>
<typeRef>uint32</typeRef>
</attribute>
<attribute elementID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat Policy</synopsis>
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</attribute>
<attribute elementID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in millisecs</synopsis>
</synopsis>
<typeRef>uint32</typeRef>
</attribute>
<attribute elementID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</attribute>
<attribute elementID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</attribute>
<attribute elementID="10" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy</synopsis>
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</attribute>
<attribute elementID="11" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy</synopsis>
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</attribute>
<attribute elementID="12" access="read-write">
<name>CETI</name>
<synopsis>
The CE Timeout Interval in millisecs</synopsis>
</synopsis>
<typeRef>uint32</typeRef>
</attribute> </attribute>
</attributes> </attributes>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
C.1 Events C.1. Capabilities
At the moment only one event, HBstate, can be subscribed to by the
CE.
By subscribing to the HBstate event, the CE infact kicks the FE into
motion to start issuing heartbeats.
C.2 Capabilities
At the moment only the SupportableVersions capability is owned by At the moment only the SupportableVersions capability is owned by
this LFB. this LFB.
Supportable Versions enumerates all ForCES versions that an FE Supportable Versions enumerates all ForCES versions that an FE
supports. supports.
C.3 Attributes C.2. Attributes
C.3.1 HBI All Attributes are explained in Section 6.2.1.
This attribute carries the Heartbeat Interval of the heartbeat from Appendix D. Data Encoding Examples
the FE -> CE in millisecs. The value of this interval is by default
set by the FE but could be overwritten in the association setup by
the CE.
TBD (this really belongs in the protocol draft but here for capture We give a few examples below but dont show the padding.
purposes:
Define it as simply that the CE and FE must hear from each other at ==========
the configured interval. The FE on her side generates a heartbeat Example 1:
notification if he has nothing else to say. In otehr words, The lack ==========
of any messages from the CE to which the FE responded to after a
period of HBI will result in a FE firing a HB message. The lack of
any message within DeadInterval will force the FE to ask for an ACK
for its HB message (by setting the ACK flag in the header).
Other adaptive heartbeats schemes which could be used: have the CE Structure with three fixed-lengthof, mandatory fields.
adjust the FE timers depending on the number of FEs present.
Example, its 1 sec for upto 100 FEs and 2 seconds for [101,200] 4
seconds interval for > 200 nodes etc ... Some adaptation of this is
used by mmusic mbus protocol.
C.3.2 HBDI struct S {
uint16 a
uint16 b
uint16 c
}
This attribute carries the Heartbeat Dead Interval in millisecs. (a) Describing all fields using SPARSEDATA
TBD: Path-Data TLV
Path to an instance of S ...
SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b)
ElementIDof(c), lengthof(c), valueof(c)
The original goal for HBDI was for HA purposes - to discover if the (b) Describing a subset of fields
CE is still around by sending a heartbeat message to the CE with an
ACK flag in the mainheader to request for a response. This hasnt
been discussed in details yet; however, the general view at the time
was for the FE to associate (failover) to another CE after that
deadinterval period of not hearing from the CE - as defined by policy
which resides in that same LFB definition. Two such failover
methodologies are mentiooned briefly infact in the protocol draft but
since the current attributes are unknown, the details are missing
from the xml.
C.3.3 CurrentRunningVersion Path-Data TLV
Path to an instance of S ...
SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c)
This attribute describes which version of ForCES is currently Note: Even though we have non-optional elements in structure S, since
running. we can uniquely identify elements, we can selectively send element of
structure S (eg in the case of an update from CE to FE).
Appendix D. Use Cases (c) Describing all fields using a FULLDATA TLV
Path-Data TLV
Path to an instance of S ...
FULLDATA TLV
valueof(a)
valueof(b)
valueof(c)
==========
Example 2:
==========
Structure with three fixed-lengthof fields, one mandatory, two
optional.
struct T {
uint16 a
uint16 b (optional)
uint16 c (optional)
}
This example is identical to Example 1, as illustrated below.
(a) Describing all fields using SPARSEDATA
Path-Data TLV
Path to an instance of S ...
SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b)
ElementIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA
Path-Data TLV
Path to an instance of S ...
SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c)
(c) Describing all fields using a FULLDATA TLV
Path-Data TLV
Path to an instance of S ...
FULLDATA TLV
valueof(a)
valueof(b)
valueof(c)
Note: FULLDATA TLV _cannot_ be used unless all fields are being
described.
==========
Example 3:
==========
Structure with a mix of fixed-lengthof and variable-lengthof fields,
some mandatory, some optional (would be a good idea to show unions
maybe).
struct U {
uint16 a
string b (optional)
uint16 c (optional)
}
(a) Describing all fields using SPARSEDATA
Path to an instance of U ...
SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b)
ElementIDof(c), lengthof(c), valueof(c)
(b) Describing a subset of fields using SPARSEDATA
Path to an instance of U ...
SPARSEDATA TLV
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c)
(c) Describing all fields using FULLDATA TLV
Path to an instance of U ...
FULLDATA TLV
valueof(a)
FULLDATA TLV
valueof(b)
valueof(c)
Note: The variable-length field requires the addition of a FULLDATA
TLV within the outer FULLDATA TLV as in the case of element b above.
==========
Example 4:
==========
Structure containing an array of another structure type.
struct V {
uint32 x
uint32 y
struct U z[]
}
(a) Encoding using SPARSEDATA, with two instances of z[], also
described with SPARSEDATA, assuming only the 10th and 15th subscript
of z[] are encoded.
path to instance of V ...
SPARSEDATA TLV
ElementIDof(x), lengthof(x), valueof(x)
ElementIDof(y), lengthof(y), valueof(y)
ElementIDof(z), lengthof(all below)
ElementID = 10 (i.e index 10 from z[]), lengthof(all below)
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(b), lengthof(b), valueof(b)
ElementID = 15 (index 15 from z[]), lengthof(all below)
ElementIDof(a), lengthof(a), valueof(a)
ElementIDof(c), lengthof(c), valueof(c)
Note the holes in the elements of z (10 followed by 15). Also note
the gap in index 15 with only elements a and c appearing but not b.
Appendix E. Use Cases
Assume LFB with following attributes for the following use cases. Assume LFB with following attributes for the following use cases.
foo1, type u32, ID = 1 foo1, type u32, ID = 1
foo2, type u32, ID = 2 foo2, type u32, ID = 2
table1: type array, ID = 3 table1: type array, ID = 3
elements are: elements are:
t1, type u32, ID = 1 t1, type u32, ID = 1
skipping to change at page 80, line 9 skipping to change at page 92, line 9
x1, ID 1, type u32 x1, ID 1, type u32
x2, ID2 , type u32 x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1} KEY: tkey, ID = 1, V = { x1}
All examples will show an attribute suffixed with "v" or "val" to All examples will show an attribute suffixed with "v" or "val" to
indicate the value of the referenced attribute. example for attribute indicate the value of the referenced attribute. example for attribute
foo2, foo1v or foo1value will indicate the value of foo1. In the foo2, foo1v or foo1value will indicate the value of foo1. In the
case where F_SEL** are missing (bits equal to 00) then the flags will case where F_SEL** are missing (bits equal to 00) then the flags will
not show any selection. not show any selection.
All the examples only show use of FULLDATA for data encoding;
although SPARSEDATA would make more sense in certain occassions, the
emphasis is on showing the message layout. Refer to Appendix D for
examples that show usage of both FULLDATA and SPARSEDATA.
1. To get foo1 1. To get foo1
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: IDCount = 1, IDs = 1 Path-data TLV: IDCount = 1, IDs = 1
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags=0, IDCount = 1, IDs = 1 flags=0, IDCount = 1, IDs = 1
DATARAW-TLV L = 4+4, V = foo1v FULLDATA-TLV L = 4+4, V = foo1v
2. To set foo2 to 10 2. To set foo2 to 10
OPER = SET-REPLACE-TLV OPER = SET-REPLACE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
DATARAW TLV: L = 4+4, V=10 FULLDATA TLV: L = 4+4, V=10
Result: Result:
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
RESULT-TLV RESULT-TLV
3. To dump table2 3. To dump table2
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
IDCount = 1, IDs = 4 IDCount = 1, IDs = 4
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
DATARAW=TLV: L = XXX, V= FULLDATA=TLV: L = XXX, V=
a series of: index, j1value,j2value entries a series of: index, j1value,j2value entries
representing the entire table representing the entire table
4. Note: One should be able to take a GET-RESPONSE-TLV and convert 4. Note: One should be able to take a GET-RESPONSE-TLV and convert
it to a SET-REPLACE-TLV. If the result in the above example is it to a SET-REPLACE-TLV. If the result in the above example is
sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV)
then the entire contents of the table will be replaced at that then the entire contents of the table will be replaced at that
point. point.
5. Multiple operations Example. To create entry 0-5 of table2 5. Multiple operations Example. To create entry 0-5 of table2
(Ignore error conditions for now) (Ignore error conditions for now)
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data-TLV: Path-data-TLV:
skipping to change at page 82, line 9 skipping to change at page 94, line 9
then the entire contents of the table will be replaced at that then the entire contents of the table will be replaced at that
point. point.
5. Multiple operations Example. To create entry 0-5 of table2 5. Multiple operations Example. To create entry 0-5 of table2
(Ignore error conditions for now) (Ignore error conditions for now)
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
DATARAW-TLV containing j1, j2 value for entry 0 FULLDATA-TLV containing j1, j2 value for entry 0
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
DATARAW-TLV containing j1, j2 value for entry 1 FULLDATA-TLV containing j1, j2 value for entry 1
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
DATARAW-TLV containing j1, j2 value for entry 2 FULLDATA-TLV containing j1, j2 value for entry 2
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
DATARAW-TLV containing j1, j2 value for entry 3 FULLDATA-TLV containing j1, j2 value for entry 3
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
DATARAW-TLV containing j1, j2 value for entry 4 FULLDATA-TLV containing j1, j2 value for entry 4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
DATARAW-TLV containing j1, j2 value for entry 5 FULLDATA-TLV containing j1, j2 value for entry 5
Result: Result:
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
RESULT-TLV RESULT-TLV
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
skipping to change at page 83, line 12 skipping to change at page 95, line 12
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
RESULT-TLV RESULT-TLV
6. Block operations (with holes) example. Replace entry 0,2 of 6. Block operations (with holes) example. Replace entry 0,2 of
table2 table2
OPER = SET-REPLACE-TLV OPER = SET-REPLACE-TLV
Path-data TLV: Path-data TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
DATARAW-TLV containing j1, j2 value for entry 0 FULLDATA-TLV containing j1, j2 value for entry 0
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
DATARAW-TLV containing j1, j2 value for entry 2 FULLDATA-TLV containing j1, j2 value for entry 2
Result: Result:
OPER = SET-REPLACE-TLV OPER = SET-REPLACE-TLV
Path-data TLV: Path-data TLV:
flags = 0 , IDCount = 1, IDs=4 flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
RESULT-TLV RESULT-TLV
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
skipping to change at page 83, line 38 skipping to change at page 95, line 38
7. Getting rows example. Get first entry of table2. 7. Getting rows example. Get first entry of table2.
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: Path-data TLV:
IDCount = 2, IDs=4.0 IDCount = 2, IDs=4.0
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
IDCount = 2, IDs=4.0 IDCount = 2, IDs=4.0
DATARAW TLV, Length = XXX, V = FULLDATA TLV, Length = XXX, V =
j1value,j2value entry j1value,j2value entry
8. Get entry 0-5 of table2. 8. Get entry 0-5 of table2.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs=4 flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV PATH-DATA-TLV
skipping to change at page 84, line 27 skipping to change at page 96, line 27
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 1, IDs=4 flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0 flags = 0, IDCount = 1, IDs = 0
DATARAW-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1 flags = 0, IDCount = 1, IDs = 1
DATARAW-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2 flags = 0, IDCount = 1, IDs = 2
DATARAW-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3 flags = 0, IDCount = 1, IDs = 3
DATARAW-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4 flags = 0, IDCount = 1, IDs = 4
DATARAW-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
PATH-DATA-TLV PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5 flags = 0, IDCount = 1, IDs = 5
DATARAW-TLV containing j1value j2value FULLDATA-TLV containing j1value j2value
9. Create a row in table2, index 5. 9. Create a row in table2, index 5.
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data-TLV: Path-data-TLV:
flags = 0, IDCount = 2, IDs=4.5 flags = 0, IDCount = 2, IDs=4.5
DATARAW TLV, Length = XXX FULLDATA TLV, Length = XXX
j1value,j2value j1value,j2value
Result: Result:
OPER = SET-RESPONSE-TLV OPER = SET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=4.5 flags = 0, IDCount = 1, IDs=4.5
RESULT-TLV RESULT-TLV
10. An example of "create and give me an index" Assuming we asked 10. An example of "create and give me an index" Assuming we asked
for verbose response back in the main message header. for verbose response back in the main message header.
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-data -TLV: Path-data -TLV:
flags = FIND-EMPTY, IDCount = 1, IDs=4 flags = FIND-EMPTY, IDCount = 1, IDs=4
DATARAW TLV, Length = XXX FULLDATA TLV, Length = XXX
j1value,j2value j1value,j2value
Result Result
If 7 were the first unused entry in the table: If 7 were the first unused entry in the table:
OPER = SET-RESPONSE OPER = SET-RESPONSE
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 2, IDs=4.7 flags = 0, IDCount = 2, IDs=4.7
RESULT-TLV indicating success, and RESULT-TLV indicating success, and
DATARAW-TLV, Length = XXX j1value,j2value FULLDATA-TLV, Length = XXX j1value,j2value
11. Dump contents of table1. 11. Dump contents of table1.
OPER = GET-TLV OPER = GET-TLV
Path-data TLV: Path-data TLV:
flags = 0, IDCount = 1, IDs=3 flags = 0, IDCount = 1, IDs=3
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV Path-data TLV
flags = 0, IDCount = 1, IDs=3 flags = 0, IDCount = 1, IDs=3
DATARAW TLV, Length = XXXX FULLDATA TLV, Length = XXXX
(depending on size of table1) (depending on size of table1)
index, t1value, t2value index, t1value, t2value
index, t1value, t2value index, t1value, t2value
. .
. .
. .
12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 12. Using Keys. Get row entry from table4 where j1=100. Recall, j1
is a defined key for this table and its keyid is 1. is a defined key for this table and its keyid is 1.
skipping to change at page 86, line 21 skipping to change at page 98, line 21
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
DATARAW TLV, Length = XXXX FULLDATA TLV, Length = XXXX
j1value,j2value, j3value, j4value j1value,j2value, j3value, j4value
13. Delete row with KEY match (j1=100, j2=200) in table 2. Note 13. 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 (with DATARAW if verbose) RESULT-TLV (with FULLDATA if verbose)
14. Dump contents of table3. It should be noted that this table has 14. 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
of this use case is to show how such an element is to be of this use case is to show how such an element is to be
encoded. encoded.
OPER = GET-TLV OPER = GET-TLV
Path-data-TLV: Path-data-TLV:
flags = 0 IDCount = 1, IDs=5 flags = 0 IDCount = 1, IDs=5
Result: Result:
OPER = GET-RESPONSE-TLV OPER = GET-RESPONSE-TLV
Path-data TLV: Path-data TLV:
flags = 0 IDCount = 1, IDs=5 flags = 0 IDCount = 1, IDs=5
DATARAW TLV, Length = XXXX FULLDATA TLV, Length = XXXX
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev),
V = namev V = namev
. .
. .
. .
15. Multiple atomic operations. 15. Multiple atomic operations.
16. Note: This emulates adding a new nexthop entry and then 16. Note: This emulates adding a new nexthop entry and then
atomically updating the L3 entries pointing to an old NH to atomically updating the L3 entries pointing to an old NH to
point to a new one. The assumption is both tables are in the point to a new one. The assumption is both tables are in the
same LFB same LFB
17. Main header has atomic flag set and we are request for verbose/ 17. Main header has atomic flag set and we are request for verbose/
full results back; Two operations on the LFB instance, both are full results back; Two operations on the LFB instance, both are
SET operations. SET operations.
//Operation 1: Add a new entry to table2 index #20. //Operation 1: Add a new entry to table2 index #20.
OPER = SET-CREATE-TLV OPER = SET-CREATE-TLV
Path-TLV: Path-TLV:
flags = 0, IDCount = 2, IDs=4.20 flags = 0, IDCount = 2, IDs=4.20
DATARAW TLV, V= j1value,j2value FULLDATA TLV, V= j1value,j2value
// 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-REPLACE-TLV OPER = SET-REPLACE-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
DATARAW 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
DATARAW TLV, V = j1value,j2value