draft-ietf-forces-protocol-01.txt   draft-ietf-forces-protocol-02.txt 
Network Working Group A. Doria (co-editor) Network Working Group A. Doria (co-editor)
Internet-Draft ETRI Internet-Draft ETRI
Expires: April 25, 2005 October 25, 2004 Expires: August 24, 2005 February 20, 2005
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-01.txt draft-ietf-forces-protocol-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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 April 25, 2005. This Internet-Draft will expire on August 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This specification documents the Forwarding and Control Element This specification documents the Forwarding and Control Element
Separation protocol. This protocol is designed to be used between a Separation protocol. This protocol is designed to be used between a
Control Element and a Forwarding Element in a Routing Network Control Element and a Forwarding Element in a Routing Network
Element. Element.
Authors Authors
The participants in the ForCES Protocol Team, co-authors and The participants in the ForCES Protocol Team, co-authors and
co-editors, of this draft, are: co-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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
skipping to change at page 2, line 24 skipping to change at page 2, line 25
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 8 3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 8
3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 11 3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 11
3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 11 3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 11
3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 12 3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 12
3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 12 3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 12
3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 13 3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 13
3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 14 3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 14
3.3.1 Of Transactions, Atomicity and 2 Phase Commits . . . . 14 3.3.1 Transactions, Atomicity, Execution and Responses . . . 14
3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . . 15 3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . . 17
3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 15 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 18
4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 17 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 18 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 20
5. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 19 5. Message encapsulation . . . . . . . . . . . . . . . . . . . . 21
6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 22 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 21
6.1 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . . 22 5.2 Type Length Value . . . . . . . . . . . . . . . . . . . . 24
6.1.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . . 23 5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . . 24
6.1.2 FE LFB . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . . 24
6.1.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . . 24 6. Protocol Construction . . . . . . . . . . . . . . . . . . . . 26
6.2 Association Messages . . . . . . . . . . . . . . . . . . . 25 6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . . 26
6.2.1 Association Setup Message . . . . . . . . . . . . . . 25 6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . . 26
6.2.2 Association Setup Response Message . . . . . . . . . . 27 6.1.2 Protocol Visualization . . . . . . . . . . . . . . . . 30
6.2.3 Association Teardown Message . . . . . . . . . . . . . 29 6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . . 33
6.3 Configuration Messages . . . . . . . . . . . . . . . . . . 30 6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . . 33
6.3.1 Config Message . . . . . . . . . . . . . . . . . . . . 30 6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . . 34
6.3.2 Config Response Message . . . . . . . . . . . . . . . 32 6.2.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4 Query and Query Response Messages . . . . . . . . . . . . 34 6.3 Semantics of message Direction . . . . . . . . . . . . . . 35
6.4.1 Query Message . . . . . . . . . . . . . . . . . . . . 34 6.4 Association Messages . . . . . . . . . . . . . . . . . . . 35
6.4.2 Query Response Message . . . . . . . . . . . . . . . . 36 6.4.1 Association Setup Message . . . . . . . . . . . . . . 36
6.5 Event Notification and Response Messages . . . . . . . . . 37 6.4.2 Association Setup Response Message . . . . . . . . . . 38
6.5.1 Event Notification Message . . . . . . . . . . . . . . 38 6.4.3 Association Teardown Message . . . . . . . . . . . . . 40
6.5.2 Event Notification Response Message . . . . . . . . . 40 6.5 Configuration Messages . . . . . . . . . . . . . . . . . . 41
6.6 Packet Redirect Message . . . . . . . . . . . . . . . . . 41 6.5.1 Config Message . . . . . . . . . . . . . . . . . . . . 42
6.7 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 45 6.5.2 Config Response Message . . . . . . . . . . . . . . . 43
6.8 Operation Summary . . . . . . . . . . . . . . . . . . . . 45 6.6 Query and Query Response Messages . . . . . . . . . . . . 45
7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 47 6.6.1 Query Message . . . . . . . . . . . . . . . . . . . . 45
7.1 Association Setup state . . . . . . . . . . . . . . . . . 47 6.6.2 Query Response Message . . . . . . . . . . . . . . . . 47
7.2 Association Established state or Steady State . . . . . . 48 6.7 Event Notification and Response Messages . . . . . . . . . 48
8. High Availability Support . . . . . . . . . . . . . . . . . . 51 6.7.1 Event Notification Message . . . . . . . . . . . . . . 49
8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 53 6.7.2 Event Notification Response Message . . . . . . . . . 51
9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 6.8 Packet Redirect Message . . . . . . . . . . . . . . . . . 52
9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 54 6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 56
9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 54 6.10 Operation Summary . . . . . . . . . . . . . . . . . . . . 57
9.1.2 Message authentication . . . . . . . . . . . . . . . . 55 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 58
9.2 ForCES PL and TML security service . . . . . . . . . . . . 55 7.1 Association Setup state . . . . . . . . . . . . . . . . . 58
9.2.1 Endpoint authentication service . . . . . . . . . . . 55 7.2 Association Established state or Steady State . . . . . . 59
9.2.2 Message authentication service . . . . . . . . . . . . 55 8. High Availability Support . . . . . . . . . . . . . . . . . . 62
9.2.3 Confidentiality service . . . . . . . . . . . . . . . 56 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 64
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 65
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 65
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 58 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 65
11.2 Informational References . . . . . . . . . . . . . . . . . . 58 9.1.2 Message authentication . . . . . . . . . . . . . . . . 66
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 58 9.2 ForCES PL and TML security service . . . . . . . . . . . . 66
A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 59 9.2.1 Endpoint authentication service . . . . . . . . . . . 66
B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 61 9.2.2 Message authentication service . . . . . . . . . . . . 66
C. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 62 9.2.3 Confidentiality service . . . . . . . . . . . . . . . 67
C.1 TML considerations . . . . . . . . . . . . . . . . . . . . 62 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 68
C.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 62 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69
C.1.2 Message type inference to Mapping at the TML . . . . . 63 11.1 Normative References . . . . . . . . . . . . . . . . . . . 69
D. Changes between -00 and -01 . . . . . . . . . . . . . . . . . 64 11.2 Informational References . . . . . . . . . . . . . . . . . 69
Intellectual Property and Copyright Statements . . . . . . . . 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 69
A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 70
B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 72
C. Forces Protocol LFB schema . . . . . . . . . . . . . . . . . . 73
C.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . 74
C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 74
C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . . 74
C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . . 75
C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . . 75
D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 90
E.1 TML considerations . . . . . . . . . . . . . . . . . . . . 90
E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 90
E.1.2 Message type inference to Mapping at the TML . . . . . 91
F. Changes between -01 and -02 . . . . . . . . . . . . . . . . . 92
G. Changes between -00 and -01 . . . . . . . . . . . . . . . . . 93
Intellectual Property and Copyright Statements . . . . . . . . 94
1. Introduction 1. Introduction
This specification provides a draft definition of an IP-based This specification provides a draft definition of an IP-based
protocol for Control Element control of an Forwarding Element. The protocol for Control Element control of an Forwarding Element. The
protocol is a TLV based protocol that include commands for transport protocol is a TLV based protocol that include commands for transport
of LFB information as well as TLVs for association, configuration, of LFB information as well as TLVs for association, configuration,
status, and events. status, and events.
This specification does not specify a transport mechanism for This specification does not specify a transport mechanism for
skipping to change at page 4, line 31 skipping to change at page 4, line 31
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 the TML must provide.
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 other
message types. The header is defined in Section 5, while the message types. 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. Section availability mechanisms including redundancy and fail over.
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]. We copy the definitions of some of the terminology as
indicated below: indicated below:
Addressable Entity (AE) - A physical device that is directly Addressable Entity (AE) - A physical device that is directly
skipping to change at page 12, line 25 skipping to change at page 12, line 25
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.
the following are scenarios reproduced from the Framework Document The following are scenarios reproduced from the Framework Document
to show a pre-association example. to 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)
skipping to change at page 14, line 4 skipping to change at page 14, line 4
There are three sub-phases: There are three sub-phases:
o Association setup state o Association setup state
o Established State o Established State
o Association teardown state. o Association teardown state.
3.2.2.1 Association setup state 3.2.2.1 Association setup state
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 configure (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 state, 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 state
skipping to change at page 14, line 29 skipping to change at page 14, line 29
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.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 Of Transactions, Atomicity and 2 Phase Commits 3.3.1 Transactions, Atomicity, Execution and Responses
A transaction is a sequence of operations that is guaranteed to be In the master-slave relationship the CE instructs one or more FEs on
atomic in the presence of any failures by the CEs or FEs. Operation how to execute operations and how to report back the results.
in this sense implies the PL operation within the message body TLV.
An example of a transaction could be a config PL msg with a sequence
of operations: "route-add A B,C:route-del X" (each operation in its
own TLV).
If a transaction is split across more than one message, then all This section details the different modes of execution that a CE can
messages in the the transaction MUST arrive at the destination before order the FE(s) to perform in Section 3.3.1.1. It also describes the
they are executed on either the LFB or FE. All operations are different modes a CE can ask the FE(s) to format the responses back
executed serially in the order specified by the transaction. If any after processing the operations requested in Section 3.3.1.2.
of the sequence of operations in a transaction fails then the
transaction is declared as a failure. This is an all-or-nothing
approach and is needed to ensure consistency of a transaction across
multiple FEs.
A transaction may be atomic within an FE alone or across the NE. In 3.3.1.1 Execution
both cases the atomic requirement for a transaction MUST be met. The
PL message header exposes the ability to mark a start of transaction There are two schools of thoughts which are being tossed around at
and end of transaction using flags. These flags can be used to the moment on Forces operations from the CE to the FE. We try to
derive a classical transactional two phase commit[ACID paper ref support both and leave the details to implementation (the
here]. intelligence is at the CE).
1. The CE knows exact details about the resources at the FE (memory,
table sizes, etc). When it says "SET" it knows that would work
etc. In this scenario, it is contended by the proponents of this
optimization that when a CE decides to send a command to an FE it
will work 100%. In other words, remote operations without any
transactional properties (given the CE computes the success of
the tranaaction).
2. The classical Two-phase-commit(2PC)[REference to be added here]
scheme; undo/rollback when things go wrong. undoing is initiated
by the CE after an error response from any one FE being
synchronized is received.
There are 3 execution modes that could be requested for operations
spanning on one or more LFB selectors:
Transactional all-or-none.
Any-of-N independent operations.
go-to-N loose transaction.
3.3.1.1.1 Requirements for ForCES Transactions
ForCES transactions MUST support ACIDity [ACID], defined as:
o *Atomicity*. In a transaction involving two or more discrete
pieces of information, either all of the pieces are committed or
none are.
o *Consistency*. A transaction either creates a new and valid state
of data, or, if any failure occurs, returns all data to its state
before the transaction was started.
o *Isolation*. A transaction in process and not yet committed must
remain isolated from any other transaction.
o *Durability*. Committed data is saved by the system such that,
even in the event of a failure and system restart, the data is
available in its correct state.
3.3.1.1.1.1 Transaction definition
We define a transaction as a collection of one or more ForCES
operations within one or more messages MUST have ACID properties.
3.3.1.1.1.2 Transaction protocol
A 2PC starts with a START | ATOMIC flag on its first message of a
transaction. A transaction may span multiple messages. It is up to
the CE to keep track of the different seq #s making up a transaction.
This may then be followed by more messages which are part of the same
atomic transaction.
Any failure notified by the FE causes the CE to execute an ABORT to
all FEs involved in the transaction, rolling back all previously
executed operations in the transaction.
The transaction commitment phase is signalled by an empty DONE msg
type.
TBD: We may need an ABORT message(used for rollback purposes) or
maybe a DONE with an ABORT flag to undo will suffice.
3.3.1.1.1.3 Recovery
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
has received all the responses, (possibly the DONE never reached the
FEs). At this point it is known that none of the operations failed
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
transaction. Those that completed the transaction confirm this to
the CE. Those that did not, commit the data and confirm this to the
CE. An FE that has lost all records of the transaction MUST reply
with status UNKNOWN and the actions subsequently taken by the CE are
implementation dependent.
This requires knowledge at both the CE and FE; not sure how to signal
it. Global flags: ATOMIC, START, ABORT? (used by 2PC) New msg type:
DONE, ABORT?(used by 2PC)
3.3.1.1.2 one-of-N independent operations
In which several independent operations are targeted at 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.
3.3.1.1.3 go-to-N loose transaction
In which all operations are executed on FE sequentially until first
failure. The rest of the operations are not executed but everything
upto failed is not undone unlike #1. flag: GOTON (global)
3.3.1.1.4 Relation to Multipart messages
Multipart flags apply. I.e all messages in a transaction except
for the last have a MULTIPART flag on.
There has to be consistency across the multi parts of the
messages. In other words the first message starting with mode #1
above, implies the rest do. Any inconsitency implies a cancelled
transaction in which all messages are dropped and the sender
NACKED.
3.3.1.2 Response formating
Editorial Note: This is still under discussion and ties into the
RESULT TLV discussed in Section 6.1.
3.3.2 FE, CE, and FE protocol LFBs 3.3.2 FE, CE, and FE protocol LFBs
Whereas the four key PL messages, Association Setup, Response, and All PL messages follow the LFB structure as this provides more
Teardown, as well as Heartbeat, have a specific types assigned mostly flexibility for future enhancements. This means maintanance and
for simplicity and monitoring reasons, all other PL messages follow configurability of FEs, NE, as well as the protocol require a fit in
the LFB structure as this provides more flexibility for future the LFB architecture. For this reason special LFBs are created to
enhancements. In addition, this shows how the ForCES protocol itself accomodate this need.
can be controlled by the very same type of structures (LFBs) it uses
to control functions such as IP forwarding, filtering, etc. In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc.
To achieve this, the following LFBs are used: To achieve this, the following LFBs are used:
o FE Protocol LFB o FE Protocol LFB
o FE LFB o FE LFB
o CE LFB o CE LFB
These LFBs are detailed in Section 6.1. A short description is These LFBs are detailed in Section 6.2. A short description is
provided here: provided here:
o The FE Protocol LFB is a logical entity in each FE that is used to o The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The CE operates on this LFB to control the ForCES protocol. The CE operates on this LFB to
subscribe or unsubscribe to Heartbeat messages, define the subscribe or unsubscribe to Heartbeat messages, define the
Heartbeat interval, or to discover which ForCES protocol version Heartbeat interval, or to discover which ForCES protocol version
is supported and which TMLs the FE supports. The FE Protocol LFB is supported and which TMLs the FE supports. The FE Protocol LFB
also contains the various ForCES ID to be used: unicast IDs and also contains the various ForCES ID to be used: unicast IDs a
table of the PL multicast IDs the FE must be listening to. [TBD: table of the PL multicast IDs the FE must be listening to. [TBD:
do we need a CE Protocol LFB?] do we need a CE Protocol LFB?]
o The FE LFB (referred to as "FE attributes" in the model draft) o The FE LFB (referred to as "FE attributes" in the model draft)
should not be confused with the FE Protocol Object. The FE LFB is should not be confused with the FE Protocol Object. The FE LFB is
a logical entity in each FE and contains attributes relative to a logical entity in each FE and contains attributes relative to
the FE itself, and not to the operation of the ForCES protocol the FE itself, and not to the operation of the ForCES protocol
between the CE and the FE. Such attributes can be FEState (refer between the CE and the FE. Such attributes can be FEState (refer
to model draft), vendor, etc. The FE LFB contains in particular to model draft), vendor, etc. The FE LFB contains in particular a
an table that maps a virtual LFB Instance ID to one or more table that maps a virtual LFB Instance ID to one or more Instance
Instance IDs of LFBs in the FE. IDs of LFBs in the FE.
o The CE LFB is the counterpart of the FE LFB. The CE LFB is a o The CE LFB is the counterpart of the FE LFB. The CE LFB is a
logical entity in each CE and contains attributes relative to the logical entity in each CE and contains attributes relative to the
CE itself, and not to the operation of the ForCES protocol between CE itself, and not to the operation of the ForCES protocol between
the CE and the FE. This LFB can be used to convey event the CE and the FE. This LFB can be used to convey event
notifications from a CE to FEs. Some events may be sent by the CE notifications from a CE to FEs. Some events may be sent by the CE
without prior subscription by the FEs. without prior subscription by the FEs.
3.3.3 Scaling by Concurrency 3.3.3 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.3.1 Batching
skipping to change at page 18, line 4 skipping to change at page 19, line 50
Please refer to the HA Section Section 8 for details. Please refer to the HA Section Section 8 for details.
7. Encapsulations used. 7. 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.
8. Prioritization 8. 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.
TML needs to define how this is achieved. TML needs to define how this is achieved.
9. Protection against DoS attacks
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
need to be configured. need to be configured.
o Number of transport connections o Number of transport connections
o Connection Capability, such as bandwidth, etc. o Connection Capability, such as bandwidth, etc.
o Allowed/Supported Connection QoS policy (or Congestion Control o Allowed/Supported Connection QoS policy (or Congestion Control
Policy) Policy)
5. Common Header 5. Message encapsulation
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
[Section 5.2.1].
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
0 1 2 3 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length | |version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID | | Destination ID |
skipping to change at page 19, line 30 skipping to change at page 21, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Common Header Figure 6: 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. field. Senders SHOULD set it to zero.
Command (8 bits): Command (8 bits):
Commands are defined in Section 6. Commands are defined in Section 6.
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
recognize the termination points. Ideas discussed so far are recognize the termination points. Ideas discussed so far are
desire to recognize if ID belongs to FE or CE by inspection. desire to recognize if ID belongs to FE or CE by inspection.
Suggestions for achieving this involves partitioning of the Suggestions for achieving this involves partitioning of the
ID allocation. Another alternative maybe to use flags to ID allocation. Another alternative maybe to use flags to
indicate direction (this avoids partition). indicate direction (this avoids partition).
skipping to change at page 21, line 14 skipping to change at page 23, line 21
as a TLV. as a TLV.
As an alternative, a particular multicast ID MAY be As an alternative, a particular multicast ID MAY be
associated to a given VPN ID through some configuration associated to a given VPN ID through some configuration
means. Messages delivered to such a multicast ID MUST means. Messages delivered to such a multicast ID MUST
only be applied to LFBs belonging to that VPN ID. only be applied to LFBs belonging to that VPN ID.
Sequence (32 bits) Sequence (32 bits)
Unique to a PDU. [Discussion: There may be impact on the effect Unique to a PDU. [Discussion: There may be impact on the effect
of subsequence numbers]. of subsequence numbers].
length (16 bits): Length (16 bits):
length of header + the rest of the message in DWORDS (4 byte length of header + the rest of the message in DWORDS (4 byte
increments). increments).
Flags(32 bits): Flags(32 bits):
Identified so far: Identified so far:
- ACK indicator(2 bit) - ACK indicator(2 bit)
The description for using the two bits is: The description for using the two bits is:
'NoACK' (00) 'NoACK' (00)
'SuccessACK'(01) 'SuccessACK'(01)
'UnsuccessACK'(10) 'UnsuccessACK'(10)
'ACKAll' (11) 'ACKAll' (11)
- Priority (3 bits) - Priority (3 bits)
TBD TBD
- Throttle flag - Throttle flag
- Batch (2 bits) - Batch (2 bits)
- Atomicity (1 or 2 bits) - Atomicity (1 or more bits. TBD)
Editorial Note: There are several open issues, listed below, in the Editorial Note: There are several open issues, listed below, in the
header which still need to be settled: header which still need to be settled:
1. Parallelization of PL Windowing/subsequence 1. Parallelization of PL Windowing/subsequence
Someone to look into ISCSI Someone to look into ISCSI
2. events and replies and relation to peer to peer 2. events and replies and relation to peer to peer
vs master slave vs master slave
3. We need to discuss whether some of the Flags 3. We need to discuss whether some of the Flags
such as those for Atomicity, Batching are needed such as those for Atomicity, Batching are needed
in the common header or only belong to the in the common header or only belong to the PATH
Config message. flags.
6. Protocol Messages 5.2 Type Length Value
The general structure of most messages is as follows (in BNF format): 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | variable TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (Data of size TLV length) |
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PL level PDU := MAINHDR<LFBselect>+ TLV Type:
LFBselect := LFBCLASSID LFBInstance <OPER>+
OPER := <OPERATION [<path-data>]*>+
o MAINHDR defines msg type, Target FE/CE ID etc. The MAINHDR also The TLV type field is two octets, and indicates the type of data
defines the content. As an example the content of a "config" 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:
The TLV Value field carries the data. For extensibility, the TLV
Value may be a TLV. In fact, this is the case with the
Netlink2-extension TLV. The Value encapsulated within a TLV is
dependent of the attribute being configured and is opaque to
Netlink2 and therefore is not restricted to any particular type
(example could be ascii strings such as XML, or OIDs etc).
TLVs must be 32 bit aligned.
Figure 8: TLV
5.2.1 Nested TLVs
TLV values can be other TLVs. This provides the benefits of protocol
flexibility (being able to add new extensions by introducing new TLVs
when needed). The nesting feature also allows easy mapping between
the XML LFB definitions to binary PL representation.
5.2.2 Scope of the T in TLV
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
choice to ease debugging of the protocol.
6. Protocol Construction
6.1 Protocol Grammar
The protocol construction is formally defined using a BNF-like syntax
to describe the structure of the PDU layout. This is matched to a
precise binary format later in the document.
Since the protocol is very flexible and hierachical in nature, it is
easier at times to see the visualization layout. This is provided in
Section 6.1.2
6.1.1 Protocol BNF
The format used is based on RFC 2234. The terminals of this gramar
are flags, IDcount, IDs, KEYID, KEY_DATA and DATARAW, described after
the grammar.
1. A TLV will have the word "TLV" at the end of its name
2. / is used to separate alternatives
3. parenthesised elements are treated as a single item
4. * before an item indicates 0 or more repetitions 1* before an
item indicates 1 or more repetitions
5. [] around an item indicates that it is optional (equal to *1)
The BNF of the PL level PDU is as follows:
PL level PDU := MAINHDR 1*LFBselect-TLV
LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV
OPER-TLV : = 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV
DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV
KEYINFO-TLV := KEYID KEY_DATA
DATARAW-TLV := encoded data which may nest DATARAW TLVs
RESULT-TLV := not yet defined. Holding result code and optional DATARAW
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"
message would be different from an "association" message. message would be different from an "association" message.
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 creation 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 OPERATION is one of {ADD,DEL,etc.} depending on the message type
o path-data identifies the exact element targeted. It may have zero [Editorial note: List all known operations here]
or more data values associated. o PATH-DATA-TLV identifies the exact element targeted. It may have
zero or more paths associated with it terminated by zero or more
data values associated.
* Note: SELECTOR is retained in this grammar to allow for future
extensibility.
* NOTE! NOTE! There is a selector known as BLKINFO that is left
out of this doc for now that will be revisted later. BLKINFO
is defined as:
* SELECTOR := KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV :=
[BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A
PathData can only have one selector either a KEYINFO TLV or a
BLKINFO TLV (i.e not both).
o PATH provides the path to the data being referenced.
* flags (16 bits) are used to further refine the operation to be
applied on the Path. More on these later.
* IDcount(16 bit): count of 32 bit IDs
* IDs: zero or more 32bit IDs (whose count is given by IDcount)
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
for the special case of using the entirety of the containing
context as the result of the path.
o SELECTOR is an optional construct that further defines the PATH.
Currently, the only defined selector is the KEYINFO-TLV, used for
selecting an array entry by the value of a key field. The
presence of a SELECTOR is correct only when the flags also
indicate its presence. A mismatch is a protocol format error.
o A KEYINFO TLV contains information used in content keying.
* 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
entry selection.
* KEY_DATA is the data to look for in the array, in the fields
identified by the keyfield. The information is encoded
according to the rules for the contents of a DATARAW, and
represent the field or fields which make up the key identified
by the KEYID.
o DATA may contain a DATARAW or 1 or more further PATH-DATA
selection DATARAW is only allowed on SET requests, or on responses
which return content information (GET Response for example.)
PATH-DATA may be included to extent the path on any request.
* Note: Nested PATH-DATA TLVs are supported as an efficiency
measure to permit common subexpression extraction.
* DATARAW contains "the data" whose path is selected.
o RESULT contains the indication of whether the individual SET
succeeded. If there is an indication for verbose response, then
SETRESULT will also contain the DATARAW showing the data that was
set. RESULT-TLV is included on the assumption that individual
parts of a SET request can succeed or fail separately. Note: This
is one of several ways of handling set results. This is still
being discussed.
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 operation on an addressed LFB o There can one or more operations on an addressed LFB
classid+instanceid combo(batch) classid+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 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 Core ForCES LFBs 6.1.1.1 Discussion on Grammar
Data is packed in such a way that a receiver of such data with
knowledge of the path can correlate what it means by infering in the
LFB definition. This is an optimization that helps reducing the
amount of description for the data in the protocol.
In other words:
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
information. The basis for the inference is typically the LFB class
id and the path.
OPEN ISSUE: There is another view of how DATA should be represented
posted a while back by Zsolt/Steve. We need to review it and compare
against the scheme described here. The criteria is:
o efficiency of encoding
o efficiency of parsing and decoding
o the packaging overhead.
6.1.1.1.1 Data Packing Rules
The scheme for packaging data used in this doc adheres to the
following rules:
o The Value of DATARAW TLV will contain the data being transported.
This data will be as was described in the LFB definition.
o By definition in the Forces protocol, all TLVs are 32 bit aligned.
Therefore because DATARAW is a TLV, elements not aligned in 32 bit
values will be padded.
o As an example a 16 bit value will have an extra 16 bit pad;
however two 16 bits values in a structure will be shipped together
with no padding etc.
o Variable sized data will be encapsulated inside another DATARAW
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
will contain that tables row content prefixed by its 32 bit
index/subscript OTOH, when SELECTOR flags are 00, the PATH may
contain an index pointing to a row in table; in such a case, the
RAWDATA's V will only contain the content sans the index in order
to avoid ambiguity.
6.1.1.1.2 Path Flags
The following flags are currently defined:
o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present
following this path information, and should be considered in
evaluating the path.
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
indicates that although the path identifies an array, the SET
operation should be applied to the first unused element in the
array. The result of the operation will not have this flag set,
and will have the assigned index in the path.
6.1.1.1.3 Relation of operational flags with global message flags
Should be noted that other applicable flags such as atomicity
indicators as well as verbosity result formaters are in the main
headers flags area.
6.1.1.1.4 Content Path Selection
The KEYINFO TLV describes the KEY as well as associated KEY data.
KEYs, used for content searches, are restricted and described in the
LFB definition.
6.1.1.1.5 Operation TLVs
It is assumed that specific operations are identified by the type
code of the TLV. And that response are also identified by specific
TLV opcodes
6.1.1.1.6 SET and GET Relationship
It is expected that a GET-RESPONSE would satisfy the following
desires:
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
DATARAW TLVs.
o it should be possible that one would take the same GET-RESPONSE
and convert it to a SET-REPLACE successfully by merely changing
the T in the operational TLV.
o There are exceptions to this rule:
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
cooked result is returned. Refer to the examples using KEYS
to see this.
2. When dumping a whole table in a GET, the GET-RESPONSE, merely
editing the T to be SET will endup overwritting the table.
6.1.2 Protocol Visualization
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
one or more operation.
main hdr (Config in this case)
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| +-- T = SET-CREATE
| | |
| | +-- // one or more path targets
| | // with their data here to be added
| |
| +-- T = DEL
| . |
| . +-- // one or more path targets to be deleted
|
|
+--- T = LFBselect
| |
| +-- LFBCLASSID
| |
| |
| +-- LFBInstance
| |
| + -- T= SET-REPLACE
| |
| |
| + -- T= DEL
| |
| + -- T= SET-REPLACE
|
|
+--- T = LFBselect
|
+-- LFBCLASSID
|
+-- LFBInstance
.
.
.
Figure 10: PL PDU layout
The figure below shows an example general layout of the operation
within a targetted LFB selection. The idea is to show the different
nesting levels a path could take to get to the target path.
T = SET-CREATE
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| + -- T = KEYINFO
| | + -- KEY_ID
| | + -- KEY_DATA
| |
| + -- T = DATARAW
| + -- data
|
|
T = SET-REPLACE
| |
| +- T = Path-data
| | |
| | + -- flags
| | + -- IDCount
| | + -- IDs
| | |
| | + -- T = DATARAW
| | + -- data
| +- T = Path-data
| |
| + -- flags
| + -- IDCount
| + -- IDs
| |
| + -- T = DATARAW
| + -- data
T = DEL
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
|
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
+ -- T = KEYINFO
| + -- KEY_ID
| + -- KEY_DATA
+- T = Path-data
|
+ -- flags
+ -- IDCount
+ -- IDs
Figure 11: Sample operation layout
6.2 Core ForCES LFBs
There are three LFBs that are used to control the operation of the There are three 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 LFB
CE LFB CE 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 be sent or received. All attributes in these LFBs must have
pre-defined default values. Finally, these LFBs do not have input or pre-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.1.1 FE Protocol LFB Editorial Note: The CE LFB is under discussion still and may end up
being removed.
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 LFB Instance ID is assigned the value
0x1. There must always be one and only one instance of the FE 0x1. There must always be one and only one instance of the FE
Protocol LFB in an FE. The values of the attributes in the FE Protocol LFB in an FE. The values of the attributes in the FE
Protocol LFB have pre-defined default values that are specified here. Protocol LFB have pre-defined default values that are specified here.
Unless explicit changes are made to these values using Config Unless explicit changes are made to these values using Config
messages from the CE, these default values MUST be used for the messages from the CE, these default values MUST be used for the
operation of the protocol. operation of the protocol.
The formal definition of the FE Protocol LFB can be found in
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: o FE Protocol events that can be subscribed/unsubscribed:
* FE heartbeat * FE heartbeat
* FE TML events (TBD) * FE TML events (TBD)
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 * Supported ForCES FE model(s) by the FE
* Some 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
skipping to change at page 23, line 43 skipping to change at page 34, line 20
* Association Expiry Timer * Association Expiry Timer
* Heartbeat Interval * Heartbeat Interval
* Primary CE * Primary CE
* FE failover and restart policy * FE failover and restart policy
* CE failover and restart policy * CE failover and restart policy
Note: Is there a difference between the CE and FE failover Note: Is there a difference between the CE and FE failover
policies? policies?
TBD: Define default values for each attribute where TBD: Define default values for each attribute where
applicable. applicable.
6.1.2 FE LFB 6.2.2 FE Object LFB
The FE LFB is a logical entity in each FE and contains attributes The FE Object LFB is a logical entity in each FE and contains
relative to the FE itself, and not to the operation of the ForCES attributes relative to the FE itself, and not to the operation of the
protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The
Instance ID is assigned the value 0x1. There must always be one and FE LFB Instance ID is assigned the value 0x1. There must always be
only one instance of the FE LFB in an FE. one and only one instance of the FE LFB in an FE.
The FE LFB consists of the following elements: The formal definition of the FE Object LFB can be found in [FE-MODEL]
The FE LFB consists of the following elements:
FE Events: FE Events:
* FEAllEvents: subscribing to this corresponds to subscribing to * FEAllEvents: subscribing to this corresponds to subscribing to
all events below all events below
* FEStatusChange: events that signal FE Status: * FEStatusChange: events that signal FE Status:
+ Up + Up
+ Down + Down
+ Active + Active
+ Inactive + Inactive
+ Failover + Failover
* FE DoS alert * FE DoS alert
skipping to change at page 24, line 34 skipping to change at page 35, line 12
* MIID table: a list of virtual LFB Instance IDs that map to a * MIID table: a list of virtual LFB Instance IDs that map to a
list of Instance IDs of LFBs in that FE list of Instance IDs of LFBs in that FE
* FE Behavior Exp. Timer * FE Behavior Exp. Timer
* HA Mode * HA Mode
* FE DoS protection policy * FE DoS protection policy
* FEPrivateData: Proprietary info such as name, vendor, model. * FEPrivateData: Proprietary info such as name, vendor, model.
Note: The attributes below were previously under Query Note: The attributes below were previously under Query
message. message.
* Inter-FE topology Intra-FE topology * Inter-FE topology Intra-FE topology
6.1.3 CE LFB 6.2.3 CE LFB
The CE LFB is a logical entity in each CE and contains attributes The CE LFB is a logical entity in each CE and contains attributes
relative to the CE itself, and not to the operation of the ForCES relative to the CE itself, and not to the operation of the ForCES
protocol. protocol.
Editorial Note: NOTE: The CE LFB is under discussion still and may
end up being removed.
The CE LFB consists of the following elements: The CE LFB consists of the following elements:
CE Events: CE Events:
* CEAllEvents: subscribing to this corresponds to subscribing to * CEAllEvents: subscribing to this corresponds to subscribing to
all events listed below. all events listed below.
Note: Do we want to allow an FE to explicitly subscribe to CE Note: Do we want to allow an FE to explicitly subscribe to CE
events? events?
* CEStatusChange: events that signal CE * CEStatusChange: events that signal CE
Up/Down/Active/Inactive/Failover. Up/Down/Active/Inactive/Failover.
Note: Such events do not necessarily need to be subscribed to, Note: Such events do not necessarily need to be subscribed to,
they can fire even without subscription and be sent to they can fire even without subscription and be sent to
the FE the FE
Note: TBD: what else do we need in the CE LFB? Note: TBD: what else do we need in the CE LFB?
6.2 Association Messages 6.3 Semantics of message Direction
Recall: The PL protocol provides a master(CE)-Slave(FE) relationship.
The LFBs reside at the FE and are controlled by CE.
When messages go from the CE, the LFB Selector (Class and instance)
refers to the destination LFB selection which resides in the FE.
When messages go from the FE->CE, the LFB Selector (Class and
instance) refers to the source LFB selection which resides in the FE.
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.2.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= 'Association
Setup'. The ACK flag in the header is ignored, because the setup Setup'. The ACK flag in the header is ignored, because the setup
message will always expect to get a response from the message message will always expect to get a response from the message
receiver (CE) whether the setup is successful or not. The Src ID receiver (CE) whether the setup is successful or not. 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 setup message body consists of LFBSelect & FE Name TLV, the The LFB selection points to the FE Object and more than one FE
format of which is as follows: Object attribute may be announced in this message. The layout
looks like:
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
| |
| +--- T = Operation = SHOW
| |
| +-- Path-data to one or more attibutes
| including FE NAME
+--- T = LFBselect
|
+-- LFBCLASSID = FE Protocol object
|
|
+-- LFBInstance = 0x1
| |
+--- T = Operation = SHOW +--- T = Operation = SHOW
| |
+-- FE NAME +-- Path-data to one or more attibutes
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 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 | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object | | LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length | | Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FE Name string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ FE Object LFB (including HBI, etc) ~ ~ Attributes path and data ~
~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Protocol Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~
~ Attributes path and data ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Figure 12
Type (16 bits): Type (16 bits):
LFB Select LFB Select
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: FE Object and Protocol LFBs:
This contains the FE parameters e.g. HBI will be exchanged with These contains the FE parameters e.g. HBI will be exchanged with
the CE using this LFB. the CE using the FE Protocol LFB.
FE Name String:
This is a string which contains the FE name (part of FE Object
LFB).
Editorial Note: In certain situations (such as use of multicast Editorial Note: In certain situations (such as use of multicast
IDs), it might not be possible to make use of the IDs), it might not be possible to make use of the
procedure described above for the FE to procedure described above for the FE to
dynamically obtain an ID from the CE. Such dynamically obtain an ID from the CE. Such
situations need to be identified. situations need to be identified.
6.2.2 Association Setup Response Message this message will still require some small
discussion; for now goal is to convert to
something using the two core FE LFBs.
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= 'Setup
Response'. The ACK flag in the header is always ignored, because Response'. The ACK flag in the header is always ignored, because
skipping to change at page 28, line 8 skipping to change at page 38, line 31
response from the message receiver (FE). The Dst ID in the response from the message receiver (FE). The Dst ID in the
header will be set to some FE ID value assigned by the CE if 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). FE had requested that in the setup message (by SrcID = 0).
Message body: Message body:
The setup response message body consists of LFBSelect & Result The setup response message body consists of LFBSelect & Result
TLV, the format of which is as follows: TLV, the format of which is as follows:
main hdr (eg type = Association setup response) main hdr (eg type = Association setup response)
| |
| |
|
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = FE object | +-- LFBCLASSID = FE object
| | | |
| | | |
| +-- LFBInstance = 0x1 | +-- LFBInstance = 0x1
| |
| +--- T = Operation = SHOW
| |
| +-- Path-data to one or more attibutes
| including FE NAME
| May contain RESULT TLVs
+--- T = LFBselect
| |
+--- T = FEResult +-- LFBCLASSID = FE Protocol object
| |
+-- resultvalue |
+-- LFBInstance = 0x1
|
+--- T = Operation = SHOW
|
+-- Path-data to one or more attibutes
eg HB parameters
May contain RESULT TLVs
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 | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object | | LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length | | Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ FE Object LFB (optional) ~ ~ Attributes path and data ~
| | ~ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Result | Length | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | Reserved | | LFB Class ID = FE Protocol Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
~ Attributes path and data ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10 Figure 13
Type (16 bits): Type (16 bits):
LFB Select LFB Select
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: FE Object LFB:
The FE parameters e.g. HBI may be exchanged using this LFB. The FE parameters e.g. HBI may be exchanged using this LFB.
Result (16 bits): 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 FE request was rejected by the CE.
6.2.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= "Asso.
Teardown". The ACK flag in the header is always ignored, because Teardown". The ACK flag in the header is always ignored, because
the teardown message will never expect to get any response from the teardown message will never expect to get any response from
the message receiver. the message receiver.
Message body: Message body:
The association teardown message body consists of LFBSelect & The association teardown message body consists of LFBSelect &
FEReason TLV, the format of which is as follows: FEReason TLV, the format of which is as follows:
Editorial Note: Details of how Reason will be carried in the
Teardown message are still unclear. There is no
such attribute at the FE Object at the moment.
There is also no operation by the name of
FEReason.
main hdr (eg type = Association tear) main hdr (eg type = Association tear)
| |
| |
|
|
+--- T = LFBselect +--- T = LFBselect
| |
| +-- LFBCLASSID = FE object
| |
| |
| +-- LFBInstance = 0x1
| |
+--- T = FEReason +-- LFBCLASSID = FE object
| |
+-- "myreason" |
+-- LFBInstance = 0x1
|
+--- T = Operation = FEReason
|
+-- Path-data to string containing reason
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 | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object | | LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = T.reason | Length | | Type = T.reason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
Figure 14
Type (16 bits): Type (16 bits):
LFB Select LFB Select
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.
T.reason (32 bits): T.reason (32 bits):
This indicates the reason why the association is being This indicates the reason why the association is being
terminated. terminated.
6.3 Configuration Messages 6.5 Configuration Messages
The ForCES Configuration messages are used by the CEs to configure The ForCES Configuration messages are used by the CEs to configure
the FEs in a ForCES NE and report the results back to the CE. the FEs in a ForCES NE and report the results back to the CE.
6.3.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 FE or LFB
attributes. This message is also used by the CE to attributes. This message is also used by the CE to
subscribe/unsubscribe to FE and LFB events. subscribe/unsubscribe to FE and LFB events.
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 is can be used by the CE to turn off any
skipping to change at page 30, line 47 skipping to change at page 42, line 33
| |
| |
+--- T = LFBselect +--- T = LFBselect
| | | |
| +-- LFBCLASSID = target LFB class | +-- LFBCLASSID = target LFB class
| | | |
| | | |
| +-- LFBInstance = target LFB instance | +-- LFBInstance = target LFB instance
| | | |
| | | |
| +-- T = operation { ADD, DEL, etc} | +-- T = operation { GET, DEL, etc}
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | | // discussed later
| | | |
| +-- T = operation { ADD, DEL, etc} | +-- T = operation { GET, DEL, etc}
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | | // discussed later
| | | |
| +-- T = operation { ADD, DEL, etc} | +-- T = operation { GET, DEL, etc}
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | | // 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 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 | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Operations (ADD) | Length | | Operation (GET) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Config data ~ ~ Config path ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Operations (DEL) | Length | | Operations (DEL) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Config data ~ ~ Config path ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 Figure 15
Type (16 bits): Type (16 bits):
LFB Select. LFB Select.
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.
LFB Class ID (16 bits): LFB Class ID (16 bits):
This field uniquely recognizes the LFB class/type. This field uniquely recognizes the LFB class/type.
LFB Instance ID (16 bits): LFB Instance ID (16 bits):
This field uniquely identifies the LFB instance. This field uniquely identifies the LFB instance.
Type (16 bits): Type (16 bits):
The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT
SUBSCRIBE, EVENT UNSUBSCRIBE, PACKET SUBSCRIBE, PACKET SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL(under discussion).
UNSUBSCRIBE, CANCEL.
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.
Config Data (variable length): Config path + Data (variable length):
This will carry LFB specific data (<path>, single or Array LFB This will carry LFB specific data (<path>, presentation
specific entries). The config data might itself be of the form preliminary found in this doc but still TBD. ). The config data
of a TLV. might itself be of 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 *Note: FE Activate/Deactivate, Shutdown FE commands for State
Maintenance will be sent using Config messages. Maintenance will be sent using Config messages.
*Note: For Event subscription, the events will be defines by the *Note: For Event subscription, the events will be defines by the
individual LFBs. individual LFBs.
6.3.2 Config Response Message 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
skipping to change at page 33, line 14 skipping to change at page 44, line 28
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 | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Operations (ADD) | Length | | Operations (GET) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Result | reserved | | Operation Result | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Config Result ~ ~ Config Result ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Operations (DEL) | Length | | Type = Operations (DEL) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Result | reserved | | Operation Result | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Config Result ~ ~ Config Result ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 Figure 16
Editorial Note: The operation result etc is still under
discussion and will depend on verbosity levels in the main
message headers
Type (16 bits): Type (16 bits):
LFB Select. LFB Select.
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.
LFB Class ID (16 bits): LFB Class ID (16 bits):
This field uniquely recognizes the LFB class/type. This field uniquely recognizes the LFB class/type.
LFB Instance ID (16 bits): LFB Instance ID (16 bits):
This field uniquely identifies the LFB instance. This field uniquely identifies the LFB instance.
Type (16 bits): Type (16 bits):
The operations are same as those defined for Config messages. The operations are same as those defined for Config messages.
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.
Operation Result (16 bits): Operation Result (16 bits):
This indicates the overall result of the config operation, This indicates the overall result of the config operation,
whether it was successful or it failed. whether it was successful or it failed.
Config Result (variable length): Config Result (variable length):
This will carry LFB specific results (single or Array LFB This will carry LFB specific results (single or Array LFB
specific result entries). The config result might itself be of specific result entries). The config result might itself be of
the form of a TLV. the form of a TLV.
6.4 Query and Query Response Messages 6.6 Query and Query Response Messages
The ForCES query and query response messages are used for one ForCES The ForCES query and query response messages are used by ForCES
element (CE or FE) to query other ForCES element(s) for various kinds elements (CE or FE) to query LFBs in other ForCES element(s) Current
of information. Current version of ForCES protocol limits the use of version of ForCES protocol limits the use of the messages only for CE
the messages only for CE to query information of FE. to query information of FE.
6.4.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 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'.
skipping to change at page 34, line 50 skipping to change at page 46, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 Figure 17
Editorial Note: Editorial Note:
1. Under discussion is whether there is a need 1. Under discussion is whether there is a need
for explicit multiple LFB insatance for explicit multiple LFB insatance
addressing here. One way to realize it is addressing here. One way to realize it is
to define a specific Instance select TLV to to define a specific Instance select TLV to
substitute above 'LFB Instance ID' field. substitute above 'LFB Instance ID' field.
The TLV may have following format: The TLV may have following format:
INSselectTLV := Type Length Value INSselectTLV := Type Length Value
Type := INSselect Type := INSselect
skipping to change at page 35, line 28 skipping to change at page 46, line 48
broadcast ID. Because there will be no broadcast ID. Because there will be no
broadcast address applied in this place, broadcast address applied in this place,
there will be no worry of ambiguity here. there will be no worry of ambiguity here.
Operation TLV: Operation TLV:
The Operation TLV for the 'Query' message is formatted as: The Operation TLV for the 'Query' message is formatted as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET | Length | | Type = GET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Attribute ID?) | | PATH-DATA for GET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
Figure 16 PATH-DATA for GET:
This is generically a PATH-DATA format that has been defined in
Path(or Attribute ID?): "Protocol Grammar" section in the PATH-DATA BNF definition, with
[Under discussion and TBD] the limitation specifically for GET operation that the PATH-DATA
here will not allow DATARAW-TLV and RESULT-TLV present in the
Editorial Note: There is a debate on whether we should use a data format, so as to meet the genius of a GET operation.
'Path' or simply an 'Attribute ID' or a 'Table
ID' here at the protocol layer. A Path is used
for data indexing for a table, while an
'Attribute ID' or a 'Table ID' only specify
which attribute or table to use, leaving table
index to be included in followed data.
Query Data:
[Under discussion and TBD]
To better understand the above PDU format, we can show a tree To better understand the above PDU format, we can show a tree
structure for the format as below: structure 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
skipping to change at page 36, line 31 skipping to change at page 47, line 36
| | | |
| +-- T = operation { GET } | +-- T = operation { GET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | | // under discussion
| +-- T = operation { GET } | +-- T = operation { GET }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | | |
Figure 17 Figure 20
6.4.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
skipping to change at page 37, line 19 skipping to change at page 48, line 22
is expected. If the ACK flag is set other values, the meaning of 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 the flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the query message to be SHOULD keep the same as that of the query message to be
responded, so that the query message sender can keep track of the responded, so that the query message sender can keep track of the
responses. responses.
Message body: Message body:
The message body for a query response message consists of (at The message body for a query response message consists of (at
least) one or more than one TLVs that describe query results for least) one or more than one TLVs that describe query results for
individual queried entries. The TLV is also called LFBselect individual queried entries. The TLV is also called LFBselect
TLV, and has exactly the same data format as query message, TLV, and has exactly the same data format as query message,
except the Operation TLV inside is different. The order of the except the Operation TLV content is different. The order of the
TLV here matches the TLVs in the corresponding Query message, and TLV here matches the TLVs in the corresponding Query message, and
the TLV number should keep the same. The Operation TLV here is a the TLV numbers should also keep the same. The Operation TLV
'GET-RESPONSE' TLV and the data is 'Query Response Data', as here is a 'GET-RESPONSE' TLV and the data is a 'PATH-DATA'
below: format for Query Response Data, as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = GET-RESPOSE | Length | | Type = GET-RESPOSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Attribute ID?) | | PATH-DATA for GET-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Query Response Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18 Figure 21
Query Response Data: PATH-DATA for GET-RESPONSE:
[Under discussion and TBD] 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.5 Event Notification and Response Messages 6.7 Event Notification and Response Messages
The Event Notification Message is used for one ForCES element to The Event Notification Message is used for one ForCES element to
asynchronously notify one or more other ForCES elements in the same asynchronously notify one or more other ForCES elements in the same
ForCES NE on just happened events in it. The Event Notification ForCES NE on just happened events in it. The Event Notification
Response Message is used for the receiver of the Event Notification Response Message is used for the receiver of the Event Notification
Message to acknowledge the reception of the event notification. Message to acknowledge the reception of the event notification.
Events in current ForCES protocol can be categorized into following Events in current ForCES protocol can be categorized into following
types: types:
o Events happened in CE o Events happened in CE
o Events happened in FE o Events happened in FE
Events can also be categorized into two classes according to whether Events can also be categorized into two classes according to whether
they need subscription or not. An event in one ForCES element that they need subscription or not. An event in one ForCES element that
needs to be subscribed will send notifications to other ForCES needs to be subscribed will send notifications to other ForCES
elements only when the other elements have subscribed to the element elements only when the other elements have subscribed to the element
for the event notification. How to subscribe/unsubscribe for an for the event notification. How to subscribe/unsubscribe for an
event is described in the Configure Message in Section 6.3. An event event is described in the Configure Message section. An event that
that needs not to be subscribed will always send notifications to does not need to be subscribed will always send notifications to
other ForCES elements when the event happens. An event definition other ForCES elements when the event happens. Events will be defined
made by ForCES protocol, ForCES FE model, or by vendors will state if in the ForCES FE model XML definitions for LFBs as attributes; i.e
the event needs subscription or not. they will have a path to them that can be used by the config message
to subscribe to.
Editorial Note: There is an argument that it is preferable to have Editorial Note: There is an argument that it is preferable to have
all events subscribable. all events subscribable.
6.5.1 Event Notification Message 6.7.1 Event Notification Message
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, or CE to FE
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 can
be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'.
skipping to change at page 39, line 4 skipping to change at page 50, line 21
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
Figure 22
Operation TLV: Operation TLV:
This is a TLV that describes the event to be notified, as follows: This is a TLV that describes the event to be notified, as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT | Length | | OPER = REPORT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Event ID?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Event Data | | PATH-DATA for REPORT |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20 Figure 23
Path(or Event ID): PATH-DATA for REPORT:
[Under discussion and TBD] This is generically a PATH-DATA format that has been defined in
Event Data: "Protocol Grammar" section in the PATH-DATA BNF definition. The
[Under discussion and TBD] 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 To better understand the above PDU format, we can show a tree
structure for the format as below: 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
skipping to change at page 39, line 48 skipping to change at page 51, line 25
| | | |
| +-- T = operation { REPORT } | +-- T = operation { REPORT }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | // under discussion | | // under discussion
| +-- T = operation { REPORT } | +-- T = operation { REPORT }
| | | | | |
| | +-- // one or more path targets | | +-- // one or more path targets
| | | |
Figure 21 Figure 24
6.5.2 Event Notification Response Message 6.7.2 Event Notification Response Message
After sending out an Event Notification Message, the sender may be After sending out an Event Notification Message, the sender may be
interested in ensuring that the message has been received by interested in ensuring that the message has been received by
receivers, especially when the sender thinks the event notification receivers, especially when the sender thinks the event notification
is vital for system management. An Event Notification Response is vital for system management. An Event Notification Response
Message is used for this purpose. The ACK flag in the Event Message is used for this purpose. The ACK flag in the Event
Notification Message header are used to signal if such acknowledge is Notification Message header are used to signal if such acknowledge is
requested or not by the sender. requested or not by the sender.
Detailed description of the message is as below: Detailed description of the message is as below:
Message Transfer Direction: Message Transfer Direction:
From FE to CE or from CE to FE, just inverse to the direction of >From FE to CE or from CE to FE, just inverse to the direction of
the Event Notification Message that it responses. the Event Notification Message that it responses.
Message Header: Message Header:
The Message Type in the header is set MessageType= The Message Type in the header is set MessageType=
'EventNotificationResponse'. The ACK flag in the header SHOULD be 'EventNotificationResponse'. The ACK flag in the header SHOULD be
set 'NoACK', meaning no further response for the message is set 'NoACK', meaning no further response for the message is
expected. If the ACK flag is set other values, the meaning of the expected. If the ACK flag is set other values, the meaning of the
flag will then be ignored. The Sequence Number in the header flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the message to be responded, so SHOULD keep the same as that of the message to be responded, so
that the event notificatin message sender can keep track of the that the event notificatin message sender can keep track of the
responses. responses.
skipping to change at page 40, line 28 skipping to change at page 52, line 4
the Event Notification Message that it responses. the Event Notification Message that it responses.
Message Header: Message Header:
The Message Type in the header is set MessageType= The Message Type in the header is set MessageType=
'EventNotificationResponse'. The ACK flag in the header SHOULD be 'EventNotificationResponse'. The ACK flag in the header SHOULD be
set 'NoACK', meaning no further response for the message is set 'NoACK', meaning no further response for the message is
expected. If the ACK flag is set other values, the meaning of the expected. If the ACK flag is set other values, the meaning of the
flag will then be ignored. The Sequence Number in the header flag will then be ignored. The Sequence Number in the header
SHOULD keep the same as that of the message to be responded, so SHOULD keep the same as that of the message to be responded, so
that the event notificatin message sender can keep track of the that the event notificatin message sender can keep track of the
responses. responses.
Message Body: Message Body:
The message body for an event notification response message The message body for an event notification response message
consists of (at least) one or more than one TLVs that describe the consists of (at least) one or more than one TLVs that describe the
notified events. The TLV is also called LFBselect TLV, and has notified events. The TLV is also called LFBselect TLV, and has
exactly the same data format as Event Notification Message, except exactly the same data format as Event Notification Message, except
the Operation TLV inside is different. The order of the TLV here the Operation TLV inside is different. The order of the TLV here
matches the TLVs in the corresponding Event Message, and the TLV matches the TLVs in the corresponding Event Message, and the TLV
number should keep the same. The Operation TLV here is a numbers should keep the same. The Operation TLV here is a
'REPORT-RESPONSE' TLV and the data is 'Event Response Data', as 'REPORT-RESPONSE' TLV and the data is a 'PATH-DATA' format for
below: event response data, as below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REPORT-RESPONSE | Length | | Type = REPORT-RESPONSE | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Event ID?) | | PATH-DATA for REPORT-RESPONSE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result | Reason | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22 Figure 25
Path(or Event ID?):
[Under discussion and TBD]
Result:
This describes the reception result of the event notification
message as below:
Result Value Meaning
'Success' The event has been successfully received.
'Unsuccess' The event has not been successfully received.
Reason, Code: PATH-DATA for REPORT-RESPONSE:
This describes the reason and possible error code when the message This is generically a PATH-DATA format that has been defined in
is not successfully received. Note that only the failure at the "Protocol Grammar" section in the PATH-DATA BNF definition. The
protocol layer rather than the transport layer can be handled response data will be included in the RESULT-TLV inside the
here, that is, if even the header part of the message to be PATH-DATA format.
responded can not be correctly received, the response to the
message will not be able to be generated by the receiver.
Editorial Note: There is a debate on whether the Event Editorial Note: There is a debate on whether the Event
Notification Response Message is necessary or Notification Response Message is necessary or
not. The pro for it is some event notification not. The pro for it is some event notification
senders may be interested in knowing if receivers senders may be interested in knowing if receivers
have had success/unsuccess receptions of the have had success/unsuccess receptions of the
events or not. An alternative to generate such events or not. An alternative to generate such
response is for the protocol to define a response is for the protocol to define a
universal ACK message so that it can act as universal ACK message so that it can act as
responses for any types of messages as well as responses for any types of messages as well as
the event notification messages, when the message the event notification messages, when the message
senders are interested in knowing whether the senders are interested in knowing whether the
messages have been successfully received or not messages have been successfully received or not
(different from the responses for the message (different from the responses for the message
processing results). processing results).
6.6 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 usually happen when CE and FE are jointly implementing some
high-touch operations. Packets redirected from FE to CE are the data high-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 43, line 21 skipping to change at page 54, line 33
datapath as follows: datapath as follows:
+-----------------+ +-----------+ +-----------------+ +-----------+
| RedirectTap LFB |------>| | | RedirectTap LFB |------>| |
+-----------------+ | | +-----------------+ | |
| Scheduler | | Scheduler |
From other LFB ---->| LFB | From other LFB ---->| LFB |
| | | |
+-----------+ +-----------+
Figure 24 Figure 26
By use of several 'RedirectSink' LFBs and several By use of several 'RedirectSink' LFBs and several
'RedirectTap' LFBs that connect to several different 'RedirectTap' LFBs that connect to several different
datapaths in FE forwarding plane, multiple packet datapaths in FE forwarding plane, multiple packet
redirect paths between CE and FE can be constructed. redirect paths between CE and FE can be constructed.
Thought 2: There might be another way a packet could be Thought 2: There might be another way a packet could be
redirected: directly by a forwarding path, e.g., by redirected: directly by a forwarding path, e.g., by
FPGA/ASIC/NP microcode. In such a case we do not FPGA/ASIC/NP microcode. In such a case we do not
need to put in a lot of smartness. Probably a link need to put in a lot of smartness. Probably a link
skipping to change at page 44, line 26 skipping to change at page 55, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Operation 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 'RedirectTap' LFB. If the message is from FE to CE, LFB or the 'RedirectTap' LFB. If the message is from FE to CE,
the LFB class should be 'RedirectSink'. If the message is from CE the LFB class should be 'RedirectSink'. If the message is from CE
to FE, the LFB class should be 'RedirectTap'. to FE, the LFB class should be 'RedirectTap'.
Instance ID: Instance ID:
Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB.
Operation TLV: Operation TLV:
This is a TLV describing one packet of data to be directed via the This is a TLV describing one packet of data to be directed via the
skipping to change at page 44, line 50 skipping to change at page 56, line 13
#2 in this redirector LFB. The TLV format is as follows: #2 in this redirector LFB. The TLV format is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PAYLOAD | Length | | Type = PAYLOAD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Sequence Number?) | | Path(or Sequence Number?) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Data ~ ~ Redirected Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26 Figure 28
Path(or Sequence Number?): Path(or Sequence Number?):
[Under discussion and TBD] [Under discussion and TBD]
Type: Type:
[TBD] [TBD]
Redirected Data: Redirected Data:
This field will make a detailed description of the data to be This field will make a detailed description of the data to be
redirected as well as the data itself. The encoding of the redirected as well as the data itself. The encoding of the
description is based on the ForCES FE model if the redirector LFB description is based on the ForCES FE model if the redirector LFB
is defined by FE model, or based on vendor specifications if the is defined by FE model, or based on vendor specifications if the
redirector LFB is defined by vendors. The description will redirector LFB is defined by vendors. The description will
usually include the name (or the name ID) of the redirected packet usually include the name (or the name ID) of the redirected packet
data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data
itself. It may also include some metadata (metadata name (or name itself. It may also include some metadata (metadata name (or name
ID) and its value)associated with the redirected data packet. ID) and its value)associated with the redirected data packet.
6.7 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 time interval to send the message is set by the Association Setup
Message described in Section 6.1.1. A little different from other Message described in Section 6.1.1. A little different from other
protocol messages, a Heartbeat message is only composed of a common protocol messages, a Heartbeat message is only composed of a common
header, withe the message body left empty. Detailed description of header, withe the message body left empty. Detailed description of
skipping to change at page 45, line 39 skipping to change at page 57, line 4
header, withe the message body left empty. Detailed description of header, withe 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'. The ACK flag in the header SHOULD be set to
'NoACK', meaning no response from receiver(s) is expected by the 'NoACK', meaning no response from receiver(s) is expected by the
message sender. Other values of the ACK flag will always be message sender. Other values of the ACK flag will always be
ignored by the message receiver. ignored by the message receiver.
Message Body: Message Body:
The message body is empty for the Heartbeat Message. The message body is empty for the Heartbeat Message.
6.8 Operation Summary 6.10 Operation Summary
The following tables summarize the operations and their applicabiity The following tables summarize the operations and their applicabiity
to the messages. to the messages.
No Operations for the following messages: No Operations for the following messages:
Assoc-Setup Assoc-Setup
Assoc-Setup-Resp Assoc-Setup-Resp
Assoc-Teardown Assoc-Teardown
Heartbeat Heartbeat
skipping to change at page 48, line 33 skipping to change at page 59, line 33
| Topo Query Resp | | Topo Query Resp |
|---------------------->| |---------------------->|
| | | |
| FE UP Event | | FE UP Event |
|---------------------->| |---------------------->|
| | | |
| Config-Activate FE | | Config-Activate FE |
|<----------------------| |<----------------------|
| | | |
Figure 27: Message exchange between CE and FE to establish an NE Figure 29: 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 and is
moved to the Established State or Steady state. 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
skipping to change at page 49, line 49 skipping to change at page 60, line 49
| | | |
| Heart Beat | | Heart Beat |
|<----------------------| |<----------------------|
. . . .
. . . .
| | | |
| Config-Activate FE | | Config-Activate FE |
|<----------------------| |<----------------------|
| | | |
Figure 28: Message exchange between CE and FE during steady-state Figure 30: Message exchange between CE and FE during steady-state
communication 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
skipping to change at page 52, line 30 skipping to change at page 63, line 30
4 |-----------------------|------------------->| 4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 5 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |------------------------------------------->| 6 |------------------------------------------->|
Figure 29: CE Failover for Report All mode Figure 31: 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 | | Asso Estb,Caps|exchange |
2 |<----------------------|------------------->| 2 |<----------------------|------------------->|
| | | | | |
| All msgs | | | All msgs | |
3 |<--------------------->| | 3 |<--------------------->| |
skipping to change at page 53, line 26 skipping to change at page 64, line 26
4 |-----------------------|------------------->| 4 |-----------------------|------------------->|
| | | | | |
| FAILURE | | FAILURE |
| | | |
| Event Report (pri CE down) | | Event Report (pri CE down) |
5 |------------------------------------------->| 5 |------------------------------------------->|
| | | |
| All Msgs | | All Msgs |
6 |------------------------------------------->| 6 |------------------------------------------->|
Figure 30: CE Failover for Report Primary Mode Figure 32: 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 57, line 10 skipping to change at page 68, line 10
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.[TML document] layer.[TML document]
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, and Lily L. Yang for their Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for
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
[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
[ACID] Hačrder, T. and A. Reuter, "Principles of
Transaction-Orientated Database Recovery", 1983.
[FE-MODEL] [FE-MODEL]
Yang, L., "ForCES Forwarding Element Model", Feb. 2004. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.
and S. Blake, "ForCES Forwarding Element Model", Feb.
2005.
Author's Address Author's Address
Avri Doria Avri Doria
ETRI ETRI
Phone: +1 401 663 5024 Phone: +1 401 663 5024
EMail: avri@acm.org Email: avri@acm.org
Appendix A. Individual Authors/Editors Contact 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.hzic.edu.cn
skipping to change at page 62, line 5 skipping to change at page 73, line 5
149 Jiaogong Road 149 Jiaogong Road
Hangzhou 310035 Hangzhou 310035
P.R.China P.R.China
Phone: +86-571-88057712 Phone: +86-571-88057712
EMail: wmwang@mail.hzic.edu.cn EMail: wmwang@mail.hzic.edu.cn
Appendix B. IANA considerations Appendix B. IANA considerations
tbd tbd
Appendix C. Implementation Notes Appendix C. Forces Protocol LFB schema
C.1 TML considerations The schema described below conforms to the LFB schema (language?)
described in Forces Model draft[FE-MODEL]
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ietf.org/forces/1.0/lfbmodel file:/home/hadi/xmlj1/lfbmodel.xsd" provides="FEPO">
<!-- XXX -->
<LFBClassDefs>
<LFBClassDef>
<name>FEPO</name>
<id>1</id>
<synopsis> The FE Protocol Object </synopsis>
<version>1.0</version>
<derivedFrom>baseclass</derivedFrom>
<events>
<!--
The CE sets this event attribute to "yes" to kick HBs
from the FE. By default no HBs are generated
-->
<attribute>
<name>HBstate</name>
<id>2</id>
<synopsis>Heartbeat event status(yes/no)</synopsis>
<typeRef>boolean</typeRef>
</attribute>
</events>
<!--
-->
<capabilities>
<capability>
<name>SupportableVersions</name>
<id>1</id>
<synopsis>the table of ForCES versions that FE supports</synopsis>
<array type="variable-size">
<typeRef>u8</typeRef>
</array>
</capability>
</capabilities>
<!--
ADD other attributes related to HA and failover and restart
policies later
-->
<attributes>
<attribute access="read-write">
<name>HBI</name>
<id>3</id>
<synopsis>Heartbeat Interval in millisecs</synopsis>
<typeRef>uint32</typeRef>
</attribute>
<attribute access="read-write">
<name>HBDI</name>
<id>4</id>
<synopsis>Heartbeat Dead Interval in millisecs</synopsis>
<typeRef>uint32</typeRef>
</attribute>
<attribute access="read-only">
<name>CurrentRunningVersion</name>
<id>5</id>
<synopsis>Currently running ForCES version</synopsis>
<typeRef>u8</typeRef>
</attribute>
</attributes>
<!--
-->
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
C.1 Events
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
this LFB.
SupportableVersions enumerates all ForCES versions that an FE
supports.
C.3 Attributes
C.3.1 HBI
This attribute carries the Heartbeat Interval of the heartbeat from
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
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
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
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
This attribute carries the Heartbeat Dead Interval in millisecs.
TBD:
The original goal for HBDI was for HA purposes - to discover if the
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
This attribute describes which version of ForCES is currently
running.
Appendix D. Use Cases
Assume LFB with following attributes for the following use cases.
foo1, type u32, ID = 1
foo2, type u32, ID = 2
table1: type array, ID = 3
elements are:
t1, type u32, ID = 1
t2, type u32, ID = 2 // index into table 2
KEY: nhkey, ID = 1, V = t2
table2: type array, ID = 4
elements are:
j1, type u32, ID = 1
j2, type u32, ID = 2
KEY: akey, ID = 1, V = { j1,j2 }
table3: type array, ID = 5
elements are:
someid, type u32, ID = 1
name, type string variable sized, ID = 2
table4: type array, ID = 6
elements are:
j1, type u32, ID = 1
j2, type u32, ID = 2
j3, type u32, ID = 3
j4, type u32, ID = 4
KEY: mykey, ID = 1, V = { j1}
table5: type array, ID = 7
elements are:
p1, type u32, ID = 1
p2, type array, ID = 2, array elements of type-X
Type-X:
x1, ID 1, type u32
x2, ID2 , type u32
KEY: tkey, ID = 1, V = { x1}
All examples will show an attribute suffixed with "v" or "val" to
indicate the value of the referenced attribute. example for
attribute 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 not show any selection.
1. To get foo1
OPER = GET-TLV
Path-data TLV: IDCount = 1, IDs = 1
Result:
OPER = GET-RESPONSE-TLV
Path-data-TLV:
flags=0, IDCount = 1, IDs = 1
DATARAW-TLV L = 4+4, V = foo1v
2. To set foo2 to 10
OPER = SET-REPLACE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2
DATARAW TLV: L = 4+4, V=10
Result:
OPER = SET-RESPONSE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
3. To dump table2
OPER = GET-TLV
Path-data-TLV:
IDCount = 1, IDs = 4
Result:
OPER = GET-RESPONSE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs = 4
DATARAW=TLV: L = XXX, V=
a series of: index, j1value,j2value entries
representing the entire table
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 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 point.
4. Multiple operations Example. To create entry 0-5 of table2
(Ignore error conditions for now)
OPER = SET-CREATE-TLV
Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
DATARAW-TLV containing j1, j2 value for entry 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW-TLV containing j1, j2 value for entry 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW-TLV containing j1, j2 value for entry 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW-TLV containing j1, j2 value for entry 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
DATARAW-TLV containing j1, j2 value for entry 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
DATARAW-TLV containing j1, j2 value for entry 5
Result:
OPER = SET-RESPONSE-TLV
Path-data-TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
RESULT-TLV
5. Block operations (with holes) example. Replace entry 0,2 of
table2
OPER = SET-REPLACE-TLV
Path-data TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
DATARAW-TLV containing j1, j2 value for entry 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW-TLV containing j1, j2 value for entry 2
Result:
OPER = SET-REPLACE-TLV
Path-data TLV:
flags = 0 , IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
RESULT-TLV
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
6. Getting rows example. Get first entry of table2.
OPER = GET-TLV
Path-data TLV:
IDCount = 2, IDs=4.0
Result:
OPER = GET-RESPONSE-TLV
Path-data TLV:
IDCount = 2, IDs=4.0
DATARAW TLV, Length = XXX, V =
j1value,j2value entry
7. Get entry 0-5 of table2.
OPER = GET-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
Result:
OPER = GET-RESPONSE-TLV
Path-data-TLV:
flags = 0, IDCount = 1, IDs=4
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 0
DATARAW-TLV containing j1value j2value
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW-TLV containing j1value j2value
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW-TLV containing j1value j2value
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW-TLV containing j1value j2value
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 4
DATARAW-TLV containing j1value j2value
PATH-DATA-TLV
flags = 0, IDCount = 1, IDs = 5
DATARAW-TLV containing j1value j2value
8. Create a row in table2, index 5.
OPER = SET-CREATE-TLV
Path-data-TLV:
flags = 0, IDCount = 2, IDs=4.5
DATARAW TLV, Length = XXX
j1value,j2value
Result:
OPER = SET-RESPONSE-TLV
Path-data TLV:
flags = 0, IDCount = 1, IDs=4.5
RESULT-TLV
9. An example of "create and give me an index" Assuming we asked for
verbose response back in the main message header.
OPER = SET-CREATE-TLV
Path-data -TLV:
flags = FIND-EMPTY, IDCount = 1, IDs=4
DATARAW TLV, Length = XXX
j1value,j2value
Result
If 7 were the first unused entry in the table:
OPER = SET-RESPONSE
Path-data TLV:
flags = 0, IDCount = 2, IDs=4.7
RESULT-TLV indicating success, and
DATARAW-TLV, Length = XXX j1value,j2value
10. Dump contents of table1.
OPER = GET-TLV
Path-data TLV:
flags = 0, IDCount = 1, IDs=3
Result:
OPER = GET-RESPONSE-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs=3
DATARAW TLV, Length = XXXX (depending on size of table1)
index, t1value, t2value
index, t1value, t2value
.
.
.
11. Using Keys. Get row entry from table4 where j1=100. Recall, j1
is a defined key for this table and its keyid is 1.
NOTE! NOTE!
There is still debate as to whether this must reference only 1 entry.
OPER = GET-TLV
Path-data-TLV:
flags = F_SELKEY IDCount = 1, IDs=6
KEYINFO-TLV = KEYID=1, KEY_DATA=100
Result:
If j1=100 was at index 10
OPER = GET-RESPONSE-TLV
Path-data TLV:
flags = 0, IDCount = 1, IDs=6.10
DATARAW TLV, Length = XXXX
j1value,j2value, j3value, j4value
12. 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.
OPER = DEL-TLV
Path-data TLV:
flags = F_SELKEY IDCount = 1, IDs=4
KEYINFO TLV: {KEYID =1 KEY_DATA=100,200}
Result:
If (j1=100, j2=200) was at entry 15:
OPER = DELETE-RESPONSE-TLV
Path-data TLV:
flags = 0 IDCount = 2, IDs=4.15
RESULT-TLV (with DATARAW if verbose)
13. Dump contents of table3. It should be noted that this table has
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
encoded.
OPER = GET-TLV
Path-data-TLV:
flags = 0 IDCount = 1, IDs=5
Result:
OPER = GET-RESPONSE-TLV
Path-data TLV:
flags = 0 IDCount = 1, IDs=5
DATARAW TLV, Length = XXXX
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev
index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev
.
.
.
14. Multiple atomic operations.
[This emulates adding a new nexthop entry and then atomically
updating the L3 entries pointing to an old NH to point to a new
one. The assumption is both tables are in the same LFB]
Main header has atomic flag set and we are request for
verbose/full results back;
Two operations on the LFB instance, both are SET operations.
//Operation 1: Add a new entry to table2 index #20.
OPER = SET-CREATE-TLV
Path-TLV:
flags = 0, IDCount = 2, IDs=4.20
DATARAW TLV, V= j1value,j2value
// Operation 2: Update table1 entry which
// was pointing with t2 = 10 to now point to 20
OPER = SET-REPLACE-TLV
Path-data-TLV:
flags = F_SELKEY, IDCount = 1, IDs=3
KEYINFO = KEYID=1 KEY_DATA=10
Path-data-TLV
flags = 0 IDCount = 1, IDs=2
DATARAW TLV, V= 20
Result:
//first operation, SET
OPER = SET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 3, IDs=4.20
RESULT-TLV code = success
DATARAW TLV, V = j1value,j2value
// second opertion SET - assuming entry 16 was updated
OPER = SET-RESPONSE-TLV
Path-data TLV
flags = 0 IDCount = 2, IDs=3.16
Path-Data TLV
flags = 0 IDCount = 1, IDs = 2
SET-RESULT-TLV code = success
DATARAW TLV, Length = XXXX v=20
// second opertion SET
OPER = SET-RESPONSE-TLV
Path-data TLV
flags = 0 IDCount = 1, IDs=3
KEYINFO = KEYID=1 KEY_DATA=10
Path-Data TLV
flags = 0 IDCount = 1, IDs = 2
SET-RESULT-TLV code = success
DATARAW TLV, Length = XXXX v=20
15. Selective setting (Example posted by Weiming). On table 4 --
for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3
to 300. Leave j4 as is.
PER = SET-REPLACE-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 6
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 5
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 7
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW TLV, Length = XXXX, V = {300}
Path-data TLV
flags = 0, IDCount = 1, IDs = 9
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
DATARAW TLV, Length = XXXX, V = {100}
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
DATARAW TLV, Length = XXXX, V = {200}
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
DATARAW TLV, Length = XXXX, V = {300}
Non-verbose response mode shown:
OPER = SET-RESPONSE-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 6
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 5
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 7
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 9
Path-data TLV
flags = 0, IDCount = 1, IDs = 1
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 2
RESULT-TLV
Path-data TLV
flags = 0, IDCount = 1, IDs = 3
RESULT-TLV
16. Manipulation of table of table examples. Get x1 from table10
row with index 4, inside table5 entry 10
operation = GET-TLV
Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
Results:
operation = GET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 5, IDs=7.10.2.4.1
DATARAW TLV: L=XXXX, V = {x1 value}
17. From table5's row 10 table10, get X2s based on on the value of
x1 equlaing 10 (recal x1 is KeyID 1)
operation = GET-TLV
Path-data-TLV
flag = F_SELKEY, IDCount=3, IDS = 7.10.2
KEYINFO TLV, KEYID = 1, KEYDATA = 10
Path-data TLV
IDCount = 1, IDS = 2 //select x2
Results:
If x1=10 was at entry 11:
operation = GET-RESPONSE-TLV
Path-data-TLV
flag = 0, IDCount=5, IDS = 7.10.2.11
Path-data TLV
flags = 0 IDCount = 1, IDS = 2
DATARAW TLV: L=XXXX, V = {x2 value}
18. Further example of table of table
Weiming would like to update different items on a hierachy of data.
So this example is there to show how that can be done with the
current BNF.
Consider table 6 which is defined as:
table6: type array, ID = 8
elements are:
p1, type u32, ID = 1
p2, type array, ID = 2, array elements of type type-A
type-A:
a1, type u32, ID 1,
a2, type array ID2 ,array elements of type type-B
type-B:
b1, type u32, ID 1
b2, type u32, ID 2
So lets say we wanted to set by replacing:
table6.10.p1 to 111
table6.10.p2.20.a1 to 222
table6.10.p2.20.a2.30.b1 to 333
in one message and one operation.
There are two ways to do this:
a) using nesting
operation = SET-REPLACE-TLV
Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
DATARAW TLV: L=XXXX,
V = {111}
Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
DATARAW TLV: L=XXXX,
V = {222}
Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1
DATARAW TLV: L=XXXX,
V = {333}
Result:
operation = SET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 2, IDs=6.10
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
Path-data-TLV
flags = 0 IDCount = 2, IDs=2.20
Path-data-TLV
flags = 0, IDCount = 1, IDs=1
RESULT-TLV
Path-data TLV :
flags = 0, IDCount = 3, IDs=2.30.1
RESULT-TLV
b) using a flat path data
operation = SET-REPLACE-TLV
Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1
DATARAW TLV: L=XXXX,
V = {111}
Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
DATARAW TLV: L=XXXX,
V = {222}
Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
DATARAW TLV: L=XXXX,
V = {333}
Result:
operation = SET-REPLACE-TLV
Path-data TLV :
flags = 0, IDCount = 3, IDs=6.10.1
RESULT-TLV
Path-data TLV :
flags = 0, IDCount = 5, IDs=6.10.1.20.1
RESULT-TLV
Path-data TLV :
flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1
RESULT-TLV
19. Get a whole LFB (all its attributes etc).
For example, at startup a CE might well want the entire FE OBJECT LFB.
So, in a request targetted at class 1, instance 1, one might find:
operation = GET-TLV
Path-data-TLV
flags = 0 IDCount = 0
result:
operation = GET-RESPONSE-TLV
Path-data-TLV
flags = 0 IDCount = 0
DATARAW encoding of the FE Object LFB
Appendix E. Implementation Notes
E.1 TML considerations
Having separated the PL from the TML layer, it became clear that the Having separated the PL from the TML layer, it became clear that the
TML layer needed to understand the desires of the PL layer to service TML layer needed to understand the desires of the PL layer to service
it. Example: How does the TML layer map prioritization or it. Example: How does the TML layer map prioritization or
reliability needs of a PL message? To see the challenge involved, reliability needs of a PL message? To see the challenge involved,
assume that all of the FE TML, FE PL, CE TML and CE PL are assume that all of the FE TML, FE PL, CE TML and CE PL are
implemented by different authors probably belonging to different implemented by different authors probably belonging to different
organizations. Three implementation alternatives were discussed. organizations. Three implementation alternatives were discussed.
As an example, consider a TML which defines that PL messages needing As an example, consider a TML which defines that PL messages needing
skipping to change at page 62, line 43 skipping to change at page 90, line 43
and #2 will require standardization of an API. Two ideas discussed and #2 will require standardization of an API. Two ideas discussed
for TML inference of PL messages are: for TML inference of PL messages are:
1. Looking at the flags in the header. 1. Looking at the flags in the header.
2. Looking at the message type. 2. Looking at the message type.
#1 and #2 can still be used if a single organization implements both #1 and #2 can still be used if a single organization implements both
(PL and TML) layers. It is also reasonable that one organization (PL and TML) layers. It is also reasonable that one organization
implements the TML and provides an abstraction to another implements the TML and provides an abstraction to another
organization to implement a PL layer on. organization to implement a PL layer on.
C.1.1 PL Flag inference by TML E.1.1 PL Flag inference by TML
1. Reliability 1. Reliability
This could be "signalled" from the PL to the TML via the ACK This could be "signalled" from the PL to the TML via the ACK
flag. The message type as well could be used to indicate this. flag. The message type as well could be used to indicate this.
2. No reliability 2. No reliability
Could be signalled via missing ACK flag. The message type as Could be signalled via missing ACK flag. The message type as
well could be used to indicate this. well could be used to indicate this.
3. Priorities 3. Priorities
A remapping to be defined via the FEM or the CEM interface A remapping to be defined via the FEM or the CEM interface
depending on the number of TML priorities available. depending on the number of TML priorities available.
skipping to change at page 63, line 28 skipping to change at page 91, line 28
4. Events that are intrinsic to the same CE or FE a TML is 4. Events that are intrinsic to the same CE or FE a TML is
located. These will not trigger any PL msg, instead, they located. These will not trigger any PL msg, instead, they
just act as notification to PL core (FE object). The just act as notification to PL core (FE object). The
congestion event generated at the transmission source side congestion event generated at the transmission source side
may belong to this, because it usually only needs to tell the may belong to this, because it usually only needs to tell the
upper PL at the same side rather than the opposite side that upper PL at the same side rather than the opposite side that
congestion has happened along the path. E.g., a congestion congestion has happened along the path. E.g., a congestion
event at CE TML layer only need to tell CE PL of this, rather event at CE TML layer only need to tell CE PL of this, rather
than the opposite FE via a PL msg. than the opposite FE via a PL msg.
C.1.2 Message type inference to Mapping at the TML E.1.2 Message type inference to Mapping at the TML
In this case one would define the desires of the different message In this case one would define the desires of the different message
types and what they expect from the TML. For example: types and what they expect from the TML. For example:
1. Association Setup, Teardown, Config, Query the PL will expect the 1. Association Setup, Teardown, Config, Query the PL will expect the
following services from TML: Reliable delivery and highest following services from TML: Reliable delivery and highest
prioritization. prioritization.
2. Packet Redirect, HB Message Types, and Event Reports the PL will 2. Packet Redirect, HB Message Types, and Event Reports the PL will
require the following services from TML: Medium Prioritization, require the following services from TML: Medium Prioritization,
and notifications when excessive losses are reached. and notifications when excessive losses are reached.
Appendix D. Changes between -00 and -01 Appendix F. Changes between -01 and -02
1. Renamed definitions.xml to Definitions.xml
2. Added Alistair Munro to acks list.
3. path-data additions + full BNF conformant to RFC 2234
4. Appendix C with examples. #3 and #4 are the biggest changes
incorporate many many days of discussion.
5. appendix with beginings of FE protocol LFB xml. The FE Object is
referenced as being in the Model draft
6. Some cosmetic things like:
1. For readability, introducing section 'protocol construction'
which now encapsulates 'Protocol Messages' (which used to be
a top section)
2. A new subsection "protocol grammar' goes underneath the same
section.
3. added TLV definition subsection
4. Many new "editorial notes"
7. Closure of all but one outstanding issue from the tracker.
8. Any other cosmetic changes posted (Hormuzd, David, Robert, Avri).
9. Rearranged text a little to introduce new sections to make text
more readable
10. Rewrote the atomicity section (still under construction input
text on ACID from Robert and Alistair)
11. fixed up the model reference to have all authors and added acid
reference
12. Weiming's updates to query and event msgs to add path-data.
Appendix G. Changes between -00 and -01
1. Major Protocol changes 1. Major Protocol changes
* Restructured message format to apply operation to LFB as * Restructured message format to apply operation to LFB as
opposed to having operation be the primary organizing opposed to having operation be the primary organizing
principle principle
* Worked with model team to bring the draft into harmony with * Worked with model team to bring the draft into harmony with
their model approach their model approach
2. Document changes 2. Document changes
* Replaced FE protocol Object and FE Object sections with * Replaced FE protocol Object and FE Object sections with
combined section on FE, CE and FE protocol LFBs combined section on FE, CE and FE protocol LFBs
* Removed minor version id * Removed minor version id
* Added Header flags * Added Header flags
* Added BNF description of message structure * Added BNF description of message structure
* Added tree structure description of PDUs * Added tree structure description of PDUs
* Added section on each type of LFB * Added section on each type of LFB
* Added structural description of each message * Added structural description of each message
* Moved query messages section to come after config message * Moved query messages section to come after config message
section section
* Replace state maintenance section * Replace state maintenance section
* Added section with tables showing the operations relevant to * Added section with tables showing the operations relevant to
particular messages particular messages
* Reworked HA section
* Many spelling and grammatical corrections * Many spelling and grammatical corrections
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at page 65, line 41 skipping to change at page 94, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/