draft-ietf-forces-protocol-03.txt   draft-ietf-forces-protocol-04.txt 
Network Working Group A. Doria (editor) Network Working Group A. Doria (editor)
Internet-Draft ETRI Internet-Draft ETRI
Expires: December 9, 2005 June 7, 2005 Expires: January 19, 2006 July 18, 2005
ForCES Protocol Specification ForCES Protocol Specification
draft-ietf-forces-protocol-03.txt draft-ietf-forces-protocol-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 December 9, 2005. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This specification documents the Forwarding and Control Element This 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 Transactions, Atomicity, Execution and Responses . . 14 3.3.1 Transactions, Atomicity, Execution and Responses . . 14
3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . 17 3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . 17
3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . 18 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . 18
4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 20 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 19
4.1 TML Parameterization . . . . . . . . . . . . . . . . . . 21 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . 20
5. Message encapsulation . . . . . . . . . . . . . . . . . . . 22 5. Message encapsulation . . . . . . . . . . . . . . . . . . . 21
5.1 Common Header . . . . . . . . . . . . . . . . . . . . . 22 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . 21
5.2 Type Length Value . . . . . . . . . . . . . . . . . . . 25 5.2 Type Length Value . . . . . . . . . . . . . . . . . . . 24
5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . 26 5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . 25
5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . 26 5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . 25
6. Protocol Construction . . . . . . . . . . . . . . . . . . . 27 6. Protocol Construction . . . . . . . . . . . . . . . . . . . 26
6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . 27 6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . 26
6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . 27 6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . 26
6.1.2 Protocol Visualization . . . . . . . . . . . . . . . 31 6.1.2 Protocol Visualization . . . . . . . . . . . . . . . 30
6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 34 6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 33
6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . 35 6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . 34
6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . 36 6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . 35
6.2.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . 37 6.3 Semantics of message Direction . . . . . . . . . . . . . 36
6.3 Semantics of message Direction . . . . . . . . . . . . . 38 6.4 Association Messages . . . . . . . . . . . . . . . . . . 36
6.4 Association Messages . . . . . . . . . . . . . . . . . . 38 6.4.1 Association Setup Message . . . . . . . . . . . . . 36
6.4.1 Association Setup Message . . . . . . . . . . . . . 38 6.4.2 Association Setup Response Message . . . . . . . . . 39
6.4.2 Association Setup Response Message . . . . . . . . . 40 6.4.3 Association Teardown Message . . . . . . . . . . . . 41
6.4.3 Association Teardown Message . . . . . . . . . . . . 42 6.5 Configuration Messages . . . . . . . . . . . . . . . . . 42
6.5 Configuration Messages . . . . . . . . . . . . . . . . . 44 6.5.1 Config Message . . . . . . . . . . . . . . . . . . . 42
6.5.1 Config Message . . . . . . . . . . . . . . . . . . . 44 6.5.2 Config Response Message . . . . . . . . . . . . . . 45
6.5.2 Config Response Message . . . . . . . . . . . . . . 46 6.6 Query and Query Response Messages . . . . . . . . . . . 47
6.6 Query and Query Response Messages . . . . . . . . . . . 48 6.6.1 Query Message . . . . . . . . . . . . . . . . . . . 47
6.6.1 Query Message . . . . . . . . . . . . . . . . . . . 48 6.6.2 Query Response Message . . . . . . . . . . . . . . . 49
6.6.2 Query Response Message . . . . . . . . . . . . . . . 50 6.7 Event Notification and Response Messages . . . . . . . . 50
6.7 Event Notification and Response Messages . . . . . . . . 51 6.7.1 Event Notification Message . . . . . . . . . . . . . 51
6.7.1 Event Notification Message . . . . . . . . . . . . . 52 6.7.2 Event Notification Response Message . . . . . . . . 53
6.7.2 Event Notification Response Message . . . . . . . . 54 6.8 Packet Redirect Message . . . . . . . . . . . . . . . . 54
6.8 Packet Redirect Message . . . . . . . . . . . . . . . . 55
6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . 57 6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . 57
6.10 Operation Summary . . . . . . . . . . . . . . . . . . . 58 6.10 Operation Summary . . . . . . . . . . . . . . . . . . . 58
7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 60 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 60
7.1 Association Setup state . . . . . . . . . . . . . . . . 60 7.1 Association Setup state . . . . . . . . . . . . . . . . 60
7.2 Association Established state or Steady State . . . . . 61 7.2 Association Established state or Steady State . . . . . 61
8. High Availability Support . . . . . . . . . . . . . . . . . 64 8. High Availability Support . . . . . . . . . . . . . . . . . 64
8.1 Responsibilities for HA . . . . . . . . . . . . . . . . 66 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . 66
9. Security Considerations . . . . . . . . . . . . . . . . . . 68 9. Security Considerations . . . . . . . . . . . . . . . . . . 68
9.1 No Security . . . . . . . . . . . . . . . . . . . . . . 68 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . 68
9.1.1 Endpoint Authentication . . . . . . . . . . . . . . 68 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . 68
skipping to change at page 3, line 41 skipping to change at page 3, line 40
C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . 77 C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . 77
C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . 77 C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . 77
C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . 77 C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . 77
C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . 78 C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . 78
C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . 78 C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . 78
D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 79 D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 79
E. Implementation Notes . . . . . . . . . . . . . . . . . . . . 95 E. Implementation Notes . . . . . . . . . . . . . . . . . . . . 95
E.1 TML considerations . . . . . . . . . . . . . . . . . . . 95 E.1 TML considerations . . . . . . . . . . . . . . . . . . . 95
E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . 95 E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . 95
E.1.2 Message type inference to Mapping at the TML . . . . 96 E.1.2 Message type inference to Mapping at the TML . . . . 96
F. changes between -02 and -03 . . . . . . . . . . . . . . . . 98 F. changes between -03 and -04 . . . . . . . . . . . . . . . . 98
G. Changes between -01 and -02 . . . . . . . . . . . . . . . . 99 G. changes between -02 and -03 . . . . . . . . . . . . . . . . 100
H. Changes between -00 and -01 . . . . . . . . . . . . . . . . 100 H. Changes between -01 and -02 . . . . . . . . . . . . . . . . 101
Intellectual Property and Copyright Statements . . . . . . . 101 I. Changes between -00 and -01 . . . . . . . . . . . . . . . . 102
Intellectual Property and Copyright Statements . . . . . . . 103
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 6, line 25 skipping to change at page 6, line 25
High Touch Capability - This term will be used to apply to the High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents capabilities found in some forwarders to take action on the contents
or headers of a packet based on content other than what is found in or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT, the IP header. Examples of these capabilities include NAT-PT,
firewall, and L7 content recognition. firewall, and L7 content recognition.
Datapath -- A conceptual path taken by packets within the forwarding Datapath -- A conceptual path taken by packets within the forwarding
plane inside an FE. plane inside an FE.
LFB (Logical Function Block) type -- A template representing a fine- LFB (Logical Function Block) type -- A template representing a fine-
grained, logically separable and well-defined packet processing grained, logically separable and well-defined processing operating
operation in the datapath. LFB types are the basic building blocks generally operating on packets in the datapath. LFB types are the
of the FE model. basic building blocks of the FE model.
LFB (Logical Function Block) Instance -- As a packet flows through an LFB (Logical Function Block) Instance -- As a packet flows through an
FE along a datapath, it flows through one or multiple LFB instances, FE along a datapath, it flows through one or multiple LFB instances,
with each implementing an instance of a certain LFB type. There may with each implementing an instance of a certain LFB type. There may
be multiple instances of the same LFB in an FE's datapath. Note that be multiple instances of the same LFB in an FE's datapath. Note that
we often refer to LFBs without distinguishing between LFB type and we often refer to LFBs without distinguishing between LFB type and
LFB instance when we believe the implied reference is obvious for the LFB instance when we believe the implied reference is obvious for the
given context. given context.
LFB Metadata -- Metadata is used to communicate per-packet state from LFB Metadata -- Metadata is used to communicate per-packet state from
skipping to change at page 14, line 43 skipping to change at page 14, line 43
failover as well as command windows. failover as well as command windows.
3.3.1 Transactions, Atomicity, Execution and Responses 3.3.1 Transactions, Atomicity, Execution and Responses
In the master-slave relationship the CE instructs one or more FEs on In the master-slave relationship the CE instructs one or more FEs on
how to execute operations and how to report back the results. how to execute operations and how to report back the results.
This section details the different modes of execution that a CE can This section details the different modes of execution that a CE can
order the FE(s) to perform in Section 3.3.1.1. It also describes the order the FE(s) to perform in Section 3.3.1.1. It also describes the
different modes a CE can ask the FE(s) to format the responses back different modes a CE can ask the FE(s) to format the responses back
after processing the operations requested in Section 3.3.1.2. after processing the operations requested.
3.3.1.1 Execution 3.3.1.1 Execution
There are two schools of thoughts which are being tossed around at There are 3 execution modes that could be requested for a batch of
the moment on Forces operations from the CE to the FE. We try to operations spanning on one or more LFB selectors:
support both and leave the details to implementation (the
intelligence is at the CE).
1. The CE knows exact details about the resources at the FE (memory, a. Transactional execute-all-or-none
table sizes, etc). When it says "SET" it knows that would work b. Loose transactional execute-until-failure
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] c. Non-transactional continue-execute-on-failure
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 3.3.1.1.1 'all-or-none' Atomic transaction
spanning on one or more LFB selectors:
Transactional all-or-none. A transaction maybe atomic:
Any-of-N independent operations. a. Within an FE alone
Example: updating multiple tables which are dependent on each
other. If updating one fails, then any others already updated
must be undone.
go-to-N loose transaction. b. Across the NE
Example: updating the same type of table(s) that are
interdependent across several FEs (such as L3 forwarding related
tables).
3.3.1.1.1 Requirements for ForCES Transactions 3.3.1.1.2 Transaction Definition
ForCES transactions MUST support ACIDity [ACID], defined as: We define a transaction as a collection of one or more ForCES
operations within one or more PL messages that MUST meet the ACIDity
properties[ACID], defined as:
o *Atomicity*. In a transaction involving two or more discrete o *Atomicity*. In a transaction involving two or more discrete
pieces of information, either all of the pieces are committed or pieces of information, either all of the pieces are committed or
none are. none are.
o *Consistency*. A transaction either creates a new and valid state o *Consistency*. A transaction either creates a new and valid state
of data, or, if any failure occurs, returns all data to its state of data, or, if any failure occurs, returns all data to its state
before the transaction was started. before the transaction was started.
o *Isolation*. A transaction in process and not yet committed must o *Isolation*. A transaction in process and not yet committed must
remain isolated from any other transaction. remain isolated from any other transaction.
o *Durability*. Committed data is saved by the system such that, o *Durability*. Committed data is saved by the system such that,
even in the event of a failure and system restart, the data is even in the event of a failure and system restart, the data is
available in its correct state. available in its correct state.
3.3.1.1.1.1 Transaction definition There are cases where the CE knows exact memory and implementation
details of the FE such as in the case of a FE-CE pair from the same
We define a transaction as a collection of one or more ForCES vendor where the FE-CE pair is tightly coupled. In such a case, the
operations within one or more messages MUST have ACID properties. transactional operations maybe simplified further by extra
computation at the CE. We do not discuss this view further other
than to mention it in not dissallowed. For the purpose of
interopability, we define a classical transactional protocol known as
two phase commit which meets the ACID properties to be used for
transactions.
3.3.1.1.1.2 Transaction protocol 3.3.1.1.3 Transaction protocol
A 2PC starts with a START | ATOMIC flag on its first message of a A 2PC starts with a START | ATOMIC flag on its first message of a
transaction. A transaction may span multiple messages. It is up to 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. 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 This may then be followed by more messages which are part of the same
atomic transaction. atomic transaction.
Any failure notified by the FE causes the CE to execute an ABORT to Any failure notified by the FE causes the CE to execute an ABORT to
all FEs involved in the transaction, rolling back all previously all FEs involved in the transaction, rolling back all previously
executed operations in the transaction. executed operations in the transaction.
The transaction commitment phase is signalled by an empty DONE msg The transaction commitment phase is signalled by an empty DONE msg
type. type.
TBD: We may need an ABORT message(used for rollback purposes) or 3.3.1.1.4 Recovery
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 Any of the participating FEs, or the CE, or the associations between
them, may fail after the DONE message has left the CE and before it them, may fail after the DONE message has left the CE and before it
has received all the responses, (possibly the DONE never reached the has received all the responses, (possibly the DONE never reached the
FEs). At this point it is known that none of the operations failed 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 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 FEs. The means of detecting such failures may include loss of
heartbeat (within the scope of ForCES) or mechanisms outside the heartbeat (within the scope of ForCES) or mechanisms outside the
scope of ForCES. When the associations are re-established, the CE scope of ForCES. When the associations are re-established, the CE
will discover a transaction in an intermediate state. Some FEs will will discover a transaction in an intermediate state. Some FEs will
skipping to change at page 16, line 45 skipping to change at page 16, line 44
have failed while doing so, and may, or may not, still have that have failed while doing so, and may, or may not, still have that
data. At this point the transaction enters the recovery phase. data. At this point the transaction enters the recovery phase.
The CE re-issues an empty DONE message to all FEs involved in the The CE re-issues an empty DONE message to all FEs involved in the
transaction. Those that completed the transaction confirm this to transaction. Those that completed the transaction confirm this to
the CE. Those that did not, commit the data and confirm this to the 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 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 with status UNKNOWN and the actions subsequently taken by the CE are
implementation dependent. implementation dependent.
This requires knowledge at both the CE and FE; not sure how to signal 3.3.1.1.5 continue-execute-on-failure
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 In which several independent operations are targeted at one or more
LFB selectors. Execution continues at the FE when one or more LFB selectors. Execution continues at the FE when one or more
operations fail. This mode is signalled by a missing ATOMIC flag. operations fail. This mode is signalled by a missing ATOMIC flag.
3.3.1.1.3 go-to-N loose transaction 3.3.1.1.6 execute-until-falure
In which all operations are executed on FE sequentially until first In which all operations are executed on FE sequentially until first
failure. The rest of the operations are not executed but everything failure. The rest of the operations are not executed but everything
upto failed is not undone unlike #1. flag: GOTON (global) up to failed is not undone unlike the case of all-or-none execution.
3.3.1.1.4 Relation to Multipart messages
Multipart flags apply. I.e all messages in a transaction except flag: GOTON (global)
for the last have a MULTIPART flag on.
There has to be consistency across the multi parts of the 3.3.1.1.7 Relation to Multipart messages
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 Multipart flags apply. I.e all messages in a transaction except for
the last have a MULTIPART flag on.
TBD - ISSUE 22 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.2 FE, CE, and FE protocol LFBs 3.3.2 FE, CE, and FE protocol LFBs
All PL messages follow the LFB structure as this provides more All PL messages operate on LFB structures as this provides more
flexibility for future enhancements. This means maintanance and flexibility for future enhancements. This means that maintenance and
configurability of FEs, NE, as well as the protocol require a fit in configurability of FEs, NE, as well as the ForCES protocol itself
the LFB architecture. For this reason special LFBs are created to must be expressed in terms of this LFB architecture. For this reason
accomodate this need. special LFBs are created to accomodate this need.
In addition, this shows how the ForCES protocol itself can be In addition, this shows how the ForCES protocol itself can be
controlled by the very same type of structures (LFBs) it uses to controlled by the very same type of structures (LFBs) it uses to
control functions such as IP forwarding, filtering, etc. control functions such as IP forwarding, filtering, etc.
To achieve this, the following LFBs are used: To achieve this, the following LFBs are used:
o FE Protocol LFB o FE Protocol LFB
o FE LFB o FE LFB
o CE LFB
These LFBs are detailed in Section 6.2. 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 a 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.
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 a to model draft), vendor, etc. The FE LFB contains in particular a
table that maps a virtual LFB Instance ID to one or more Instance table that maps a virtual LFB Instance ID to one or more 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
logical entity in each CE and contains attributes relative to the
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
notifications from a CE to FEs. Some events may be sent by the CE
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.
skipping to change at page 19, line 17 skipping to change at page 19, line 5
There are several batching levels at different protocol hierarchies. There are several batching levels at different protocol hierarchies.
o multiple PL PDUs can be aggregated under one TML message o multiple PL PDUs can be aggregated under one TML message
o multiple LFB classes and instances can be addressed within one PL o multiple LFB classes and instances can be addressed within one PL
PDU PDU
o Multiple operations can be addressed to a single LFB class and o Multiple operations can be addressed to a single LFB class and
instance instance
3.3.3.2 Command Pipelining
TBD - ISSUE 33
4. TML Requirements 4. TML Requirements
The requirements below are expected to be delivered by the TML. This The requirements below are expected to be delivered by the TML. This
text does not define how such mechanisms are delivered. As an text does not define how such mechanisms are delivered. As an
example they could be defined to be delivered via hardware or inter- example they could be defined to be delivered via hardware or between
TML protocol level schemes. 2 or more TML processes on different CEs or FEs in protocol level
schemes.
Each TML must describe how it contributes to achieving the listed Each TML must describe how it contributes to achieving the listed
ForCES requirements. If for any reason a TML does not provide a ForCES requirements. If for any reason a TML does not provide a
service listed below a justification needs to be provided. service listed below a justification needs to be provided.
1. Reliability 1. Reliability
As defined by RFC 3654, section 6 #6. As defined by RFC 3654, section 6 #6.
2. Security 2. Security
TML provides security services to the ForCES PL. TML layer TML provides security services to the ForCES PL. TML layer
skipping to change at page 20, line 39 skipping to change at page 19, line 40
3. Congestion Control 3. Congestion Control
The congestion control scheme used needs to be defined. The congestion control scheme used needs to be defined.
Additionally, the circumstances under which notification is sent Additionally, the circumstances under which notification is sent
to the PL to notify it of congestion must be defined. to the PL to notify it of congestion must be defined.
4. Uni/multi/broadcast addressing/delivery if any 4. Uni/multi/broadcast addressing/delivery if any
If there is any mapping between PL and TML level Uni/Multi/ If there is any mapping between PL and TML level Uni/Multi/
Broadcast addressing it needs to be defined. Broadcast addressing it needs to be defined.
5. Timeliness 5. HA decisions
6. TBD - ISSUE 21
7. HA decisions
It is expected that availability of transport links is the TML's It is expected that availability of transport links is the TML's
responsibility. However, on config basis, the PL layer may wish responsibility. However, on config basis, the PL layer may wish
to participate in link failover schemes and therefore the TML to participate in link failover schemes and therefore the TML
must support this capability. must support this capability.
Please refer to the HA Section Section 8 for details. Please refer to the HA Section Section 8 for details.
8. Encapsulations used. 6. Encapsulations used.
Different types of TMLs will encapsulate the PL messages on Different types of TMLs will encapsulate the PL messages on
different types of headers. The TML needs to specify the different types of headers. The TML needs to specify the
encapsulation used. encapsulation used.
9. Prioritization 7. Prioritization
It is expected that the TML will be able to handle up to 8 It is expected that the TML will be able to handle up to 8
priority levels needed by the PL layer and will provide priority levels needed by the PL layer and will provide
preferential treatment. preferential treatment.
TML needs to define how this is achieved. TML needs to define how this is achieved.
10. Protection against DoS attacks 8. The requirement for supporting up to 8 priority levels does not
mean that the underlying TML MUST be capable of handling up to 8
priority levels. In such an event the priority levels should be
divided between the available TML priotity levels. For example,
if the TML only support 2 priority levels, the 0-3 could go in
one TML priority level, while 4-7 could go in the other.
9. Protection against DoS attacks
As described in the Requirements RFC 3654, section 6 As described in the Requirements RFC 3654, section 6
4.1 TML Parameterization 4.1 TML Parameterization
It is expected that it should be possible to use a configuration It is expected that it should be possible to use a configuration
reference point, such as the FEM or the CEM, to configure the TML. reference point, such as the FEM or the CEM, to configure the TML.
Some of the configured parameters may include: Some of the configured parameters may include:
o PL ID o PL ID
skipping to change at page 22, line 24 skipping to change at page 21, line 24
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| rsvd | Message Type | Length | |version| rsvd | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source ID | | Source ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination ID | | Destination ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Correlator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
skipping to change at page 25, line 5 skipping to change at page 24, line 9
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).
Correlator (32 bits)
This field is used to correlate the ForCES Requests messages
(typically sent from CE to FE) with the corresponding Response
messages (typically sent from FE to CE).
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 ForCES protocol defines 8 different levels of priority (0-7).
The priority level can be used to distinguish between
different protocol message types as well as between the same
message type. For example, the REDIRECT PACKET message could
have different priorities to distinguish between Routing
protocols packets and ARP packets being redirected from FE to
CE. The Normal priority level is 1.
- Throttle flag - Throttle flag
- Batch (2 bits) - Batch (2 bits)
- Atomicity (1 or more bits. TBD) - Atomicity (1 or more bits. TBD)
5.2 Type Length Value 5.2 Type Length Value
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 27, line 45 skipping to change at page 26, line 45
PL level PDU := MAINHDR 1*LFBselect-TLV PL level PDU := MAINHDR 1*LFBselect-TLV
LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV
OPER-TLV := 1*PATH-DATA-TLV OPER-TLV := 1*PATH-DATA-TLV
PATH-DATA-TLV := PATH [DATA] PATH-DATA-TLV := PATH [DATA]
PATH := flags IDcount IDs [SELECTOR] PATH := flags IDcount IDs [SELECTOR]
SELECTOR := KEYINFO-TLV SELECTOR := KEYINFO-TLV
DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV
KEYINFO-TLV := KEYID KEY_DATA KEYINFO-TLV := KEYID KEY_DATA
DATARAW-TLV := encoded data which may nest DATARAW TLVs DATARAW-TLV := encoded data which may nest DATARAW TLVs
RESULT-TLV := not yet defined. RESULT-TLV := Holds result code and optional DATARAW
Holding result code and optional DATARAW
o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR
also defines the content. As an example the content of a "config" also defines the content. As an example the content of a "config"
message would be different from an "association" message. message would be different from an "association" message.
o LFBCLASSID is a 32 bit unique identifier per LFB class defined at o LFBCLASSID is a 32 bit unique identifier per LFB class defined at
class Definition time. class Definition time.
o LFBInstance is a 32 bit unique instance identifier of an LFB class o LFBInstance is a 32 bit unique instance identifier of an LFB class
skipping to change at page 30, line 12 skipping to change at page 29, line 12
The scheme for packaging data used in this doc adheres to the The scheme for packaging data used in this doc adheres to the
following rules: following rules:
o The Value of DATARAW TLV will contain the data being transported. o The Value of DATARAW TLV will contain the data being transported.
This data will be as was described in the LFB definition. This data will be as was described in the LFB definition.
o By definition in the Forces protocol, all TLVs are 32 bit aligned. 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 Therefore because DATARAW is a TLV, elements not aligned in 32 bit
values will be padded. values will be padded.
o As an example a 16 bit value will have an extra 16 bit pad; * 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 however two 16 bits values in a structure will be shipped
with no padding etc. together with no padding etc.
o Variable sized data will be encapsulated inside another DATARAW o Variable sized data will be encapsulated inside another DATARAW
TLV inside the V of the outer TLV. For example of this see TLV inside the V of the outer TLV. For example of this see
Appendix D example 13. Appendix D example 13.
o When a table is refered in the PATH (ids), then the RAWDATA's V o When a table is refered in the PATH (ids), then the RAWDATA's V
will contain that tables row content prefixed by its 32 bit index/ will contain that tables row content prefixed by its 32 bit index/
subscript OTOH, when SELECTOR flags are 00, the PATH may contain subscript OTOH, when PATH flags are 00, the PATH may contain an
an index pointing to a row in table; in such a case, the RAWDATA's index pointing to a row in table; in such a case, the RAWDATA's V
V will only contain the content with the index in order to avoid will only contain the content with the index in order to avoid
ambiguity. ambiguity.
6.1.1.1.2 Path Flags 6.1.1.1.2 Path Flags
The following flags are currently defined: The following flags are currently defined:
o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present
following this path information, and should be considered in following this path information, and should be considered in
evaluating the path. evaluating the path.
skipping to change at page 34, line 46 skipping to change at page 33, line 46
6.2 Core ForCES LFBs 6.2 Core ForCES LFBs
There are three LFBs that are used to control the operation of the There are 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
Although these LFBs have the same form and interface as other LFBs, Although these LFBs have the same form and interface as other LFBs,
they are special in many respects: they have fixed well-known LFB they are special in many respects: they have fixed well-known LFB
Class and Instance IDs. They are statically defined (no dynamic Class and Instance IDs. They are statically defined (no dynamic
instantiation allowed) and their status cannot be changed by the instantiation allowed) and their status cannot be changed by the
protocol: any operation to change the state of such LFBs (for protocol: any operation to change the state of such LFBs (for
instance, in order to disable the LFB) must result in an error. instance, in order to disable the LFB) must result in an error.
Moreover, these LFBs must exist before the first ForCES message can Moreover, these LFBs must exist before the first ForCES message can
be sent or received. All attributes in these LFBs must have pre- be sent or received. All attributes in these LFBs must have pre-
defined default values. Finally, these LFBs do not have input or defined default values. Finally, these LFBs do not have input or
output ports and do not integrate into the intra-FE LFB topology. output ports and do not integrate into the intra-FE LFB topology.
6.2.1 FE Protocol LFB 6.2.1 FE Protocol LFB
The FE Protocol LFB is a logical entity in each FE that is used to The FE Protocol LFB is a logical entity in each FE that is used to
control the ForCES protocol. The FE Protocol LFB Class ID is control the ForCES protocol. The FE Protocol LFB Class ID is
assigned the value 0x1. The FE LFB Instance ID is assigned the value assigned the value 0x1. The FE LFB Instance ID is assigned the value
0x1. There must always be one and only one instance of the FE 0x1. There MAY be one and only one instance of the FE Protocol LFB
Protocol LFB in an FE. The values of the attributes in the FE in an FE. The values of the attributes in the FE Protocol LFB have
Protocol LFB have pre-defined default values that are specified here. pre-defined default values that are specified here. Unless explicit
Unless explicit changes are made to these values using Config changes are made to these values using Config messages from the CE,
messages from the CE, these default values MUST be used for the 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 The formal definition of the FE Protocol LFB can be found in
Appendix C Appendix C
The FE Protocol LFB consists of the following elements: The FE Protocol LFB consists of the following elements:
o FE Protocol events that can be subscribed/unsubscribed: o FE Protocol events that can be subscribed/unsubscribed:
* FE heartbeat * FE heartbeat
* 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):
skipping to change at page 36, line 4 skipping to change at page 34, line 44
* 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
* Current version of the FE model * Current version of the FE model
* FE unicast ID * FE unicast ID
* FE multicast ID(s) (list) * FE multicast ID(s) (list)
* Association Expiry Timer * Association Expiry Timer. Defualt Value = 900 msec
* Heartbeat Interval. Defualt Value = 300 msec
* Heartbeat Interval
* Primary CE * Primary CE
* FE failover and restart policy * FE failover and restart policy - This specifies the behavior of
the FE during a CE failure and restart time interval. For
example, this would specify if the FE should continue running
or stop operation during a CE failure in the NE.
* CE failover and restart policy * CE failover and restart policy - - This specifies the behavior
of the CE during a FE failure and restart time interval. For
example, this would specify if the CE should continue running
or stop operation during a FE failure in the NE.
6.2.2 FE Object LFB 6.2.2 FE Object LFB
The FE Object LFB is a logical entity in each FE and contains The FE Object LFB is a logical entity in each FE and contains
attributes relative to the FE itself, and not to the operation of the attributes relative to the FE itself, and not to the operation of the
ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The
FE LFB Instance ID is assigned the value 0x1. There must always be FE LFB Instance ID is assigned the value 0x1. There must always be
one and only one instance of the FE LFB in an FE. one and only one instance of the FE LFB in an FE.
The formal definition of the FE Object LFB can be found in [FE-MODEL] The formal definition of the FE Object LFB can be found in [FE-MODEL]
skipping to change at page 37, line 31 skipping to change at page 36, line 31
* 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.
* Inter-FE topology Intra-FE topology * Inter-FE topology Intra-FE topology
6.2.3 CE LFB
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
protocol.
The CE LFB consists of the following elements:
CE Events:
* CEAllEvents: subscribing to this corresponds to subscribing to
all events listed below.
* CEStatusChange: events that signal CE Up/Down/Active/Inactive/
Failover.
Note: Such events do not necessarily need to be subscribed to,
they can fire even without subscription and be sent to
the FE
6.3 Semantics of message Direction 6.3 Semantics of message Direction
Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. Recall: The PL protocol provides a master(CE)-Slave(FE) relationship.
The LFBs reside at the FE and are controlled by CE. The LFBs reside at the FE and are controlled by CE.
When messages go from the CE, the LFB Selector (Class and instance) When messages go from the CE, the LFB Selector (Class and instance)
refers to the destination LFB selection which resides in the FE. refers to the destination LFB selection which resides in the FE.
When messages go from the FE->CE, the LFB Selector (Class and When messages go from the FE->CE, the LFB Selector (Class and
instance) refers to the source LFB selection which resides in the FE. instance) refers to the source LFB selection which resides in the FE.
skipping to change at page 38, line 45 skipping to change at page 37, line 20
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 LFB selection points to the FE Object and more than one FE The LFB selection may point to the FE Object and/or FE Protocol
Object attribute may be announced in this message. The layout LFBs and more than one attribute may be announced in this message
looks like: using GET-REPONSE to let the FE declare its configuration
parameters in an unsolicited manner. The layout is:
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 +--- T = LFBselect
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
| |
| |
+-- LFBInstance = 0x1 +-- LFBInstance = 0x1
| |
+--- T = Operation = SHOW
|
+-- Path-data to one or more attibutes +-- Path-data to one or more attibutes
including suggested HB parameters including suggested HB parameters
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Attributes path and data ~ ~ Attributes path and data ~
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Protocol Object | | LFB Class ID = FE Protocol Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Attributes path and data ~ ~ Attributes path and data ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12 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 and Protocol LFBs: FE Object and Protocol LFBs:
These contains the FE parameters e.g. HBI will be exchanged with These contains the FE parameters e.g. HBI may be exchanged with
the CE using the FE Protocol LFB. the CE using the FE Protocol LFB.
6.4.2 Association Setup Response Message 6.4.2 Association Setup Response Message
This message is sent by the CE to the FE in response to the Setup This message is sent by the CE to the FE in response to the Setup
message. It indicates to the FE whether the setup is successful or message. It indicates to the FE whether the setup is successful or
not, i.e. whether an association is established. not, i.e. whether an association is established.
Message transfer direction: Message transfer direction:
CE to FE CE to FE
Message Header: Message Header:
The Message Type in the header is set MessageType= 'Setup The Message Type in the header is set MessageType= 'Setup
Response'. The ACK flag in the header is always ignored, because Response'. The ACK flag in the header is always ignored, because
the setup response message will never expect to get any more the setup response message will never expect to get any more
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 LFB selection may point to the FE Object and/or FE Protocol
TLV, the format of which is as follows: LFBs and more than one attribute may be announced in this
message. The layout is:
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 | +--- T = Operation = SET
| | | |
| +-- Path-data to one or more attibutes | +-- Path-data to one or more attibutes
| including FE NAME | including FE NAME
| May contain RESULT TLVs |
+--- T = LFBselect +--- T = LFBselect
| |
+-- LFBCLASSID = FE Protocol object +-- LFBCLASSID = FE Protocol object
| |
| |
+-- LFBInstance = 0x1 +-- LFBInstance = 0x1
| |
+--- T = Operation = SHOW +--- T = Operation = SET
| |
+-- Path-data to one or more attibutes +-- Path-data to one or more attibutes
eg HB parameters 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 SET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Attributes path and data ~ ~ Attributes path and data ~
~ ~ ~ ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFB select | Length | | Type = LFB select | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Protocol Object | | LFB Class ID = FE Protocol Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = operation Show | Length | | Type = operation SET | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ ~ ~ ~
~ Attributes path and data ~ ~ Attributes path and data ~
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 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.
skipping to change at page 42, line 27 skipping to change at page 41, line 17
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. the defined values are:
0 = success
1 = FE ID invalid
2 = too many associations
3 = permission denied
6.4.3 Association Teardown Message 6.4.3 Association Teardown Message
This message can be sent by the FE or CE to any ForCES element to end This message can be sent by the FE or CE to any ForCES element to end
its ForCES association with that element. its ForCES association with that element.
Message transfer direction: Message transfer direction:
CE to FE, or FE to CE (or CE to CE) CE to FE, or FE to CE (or CE to CE)
Message Header: Message Header:
The Message Type in the header is set MessageType= "Asso. The Message Type in the header is set MessageType= "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:
main hdr (eg type = Association tear) main hdr (eg type = Association tear)
| |
| |
| |
+--- T = Teardown Reason
| |
+--- T = LFBselect +-- Teardown Reason code
|
+-- LFBCLASSID = FE object
|
|
+-- 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 = Teardown reason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID = FE Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = T.reason | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason | | Teardown Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14 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): Teardonw Reason (32 bits):
This indicates the reason why the association is being This indicates the reason why the association is being
terminated. terminated. Several reason codes are defined as follows.
0 - normal teardown by administrator
1 - error - out of memory
2 - error - application crash
255 - error - other or unspecified
6.5 Configuration Messages 6.5 Configuration Messages
The ForCES Configuration messages are used by the CEs to configure The ForCES Configuration messages are used by 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.5.1 Config Message 6.5.1 Config Message
This message is sent by the CE to the FE to configure FE or LFB This message is sent by the CE to the FE to configure FE or LFB
attributes. This message is also used by the CE to subscribe/ attributes. This message is also used by the CE to subscribe/
skipping to change at page 46, line 26 skipping to change at page 45, line 26
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, CANCEL. SUBSCRIBE, EVENT 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 path + Data (variable length): Config path + Data (variable length):
This will carry LFB specific data (<path>, presentation This will carry LFB specific data The config data will be in the
preliminary found in this doc but still TBD. ). The config data form of a TLV. Should be noted only a CREATE, REPLACE will have
might itself be of the form of a TLV. Should be noted only a data while the rest will only carry path information of what to
CREATE, REPLACE will have data while the rest will only carry DELete or GET.
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.5.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
skipping to change at page 47, line 23 skipping to change at page 46, line 23
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operations (SET) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Result | reserved | | Operation Result | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | Path-data TLV |
~ Config Result ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Operations (DEL) | Length | | Result TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation Result | reserved | | Operations (DEL-RESP) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-data TLV |
| | | |
~ Config Result ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result TLV |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16 Figure 16
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.
skipping to change at page 48, line 21 skipping to change at page 47, line 21
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): 0 = success
This will carry LFB specific results (single or Array LFB
specific result entries). The config result might itself be of 1 = FE ID invalid
the form of a TLV.
3 = permission denied
Path-data TLV
Result TLV
6.6 Query and Query Response Messages 6.6 Query and Query Response Messages
The ForCES query and query response messages are used by ForCES The ForCES query and query response messages are used by ForCES
elements (CE or FE) to query LFBs in other ForCES element(s) Current elements (CE or FE) to query LFBs in other ForCES element(s) Current
version of ForCES protocol limits the use of the messages only for CE version of ForCES protocol limits the use of the messages only for CE
to query information of FE. to query information of FE.
6.6.1 Query Message 6.6.1 Query Message
skipping to change at page 56, line 32 skipping to change at page 55, line 32
'PacketRedirect'. The ACK flags in the header SHOULD be set 'PacketRedirect'. The ACK flags in the header SHOULD be set
'NoACK', meaning no response is expected by this message. If the 'NoACK', meaning no response is expected by this message. If the
ACK flag is set other values, the meanings will be ignored. ACK flag is set other values, the meanings will be ignored.
Message Body: Message Body:
Consists of one or more TLVs, with every TLV having the following Consists of one or more TLVs, with every TLV having the following
data format: data format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = LFBselect | Length | | Type = Redirect | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Class ID | | LFB Class ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LFB Instance ID | | LFB Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV | | Meta Data TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ | Redirect Data TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Operation TLV |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25 Figure 25
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 'RedirectSource' LFB[FE-MODEL]. If the message is from
the LFB class should be 'RedirectSink'. If the message is from CE FE to CE, the LFB class should be 'RedirectSink'. If the message
to FE, the LFB class should be 'RedirectTap'. is from CE to FE, the LFB class should be 'RedirectSource'.
Instance ID: Instance ID:
Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB.
Operation TLV: Meta Data TLV:
This is a TLV describing one packet of data to be directed via the This is a TLV that specifies meta-data associated with followed
specified LFB above. The order of the data number is also the redirected data. The TLV is as follows:
order the data packet arrives the redirector LFB, that is, the
Redirected Data #1 should arrive earlier than the Redirected Data
#2 in this redirector LFB. The TLV format is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = PAYLOAD | Length | | Type = META-DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path(or Sequence Number?) | | Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Redirected Data ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data ILV |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26 Figure 26
Path(or Sequence Number?): Meta Data ILV:
[Under discussion and TBD] This is an Identifier-Length-Value format that is used to describe
one meta data. The ILV has the format as:
Type: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[TBD] | Meta Data ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Meta Data Value |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where, Meta Data ID is an identifier for the meta data, which is
usually defined by FE-Model[FE-MODEL].
Usually there are two meta data that are necessary for CE-FE
redirect operation. One is the redirected data type (e.g., IP
packet, TCP packet, or UDP Packet). For an FE->CE redirect
operation, redirected packet type meta data is usually a meta data
specified by a Classifier LFB that filter out redirected packets
from packet stream and sends the packets to Redirect Sink LFB.
For an CE->FE redirect operation, the redirected packet type meta
data is usually directly generated by CE.
Another meta data that should be associated with redirected data
is the port number in a redirect LFB. For a RedirectSink LFB, the
port number meta data tells CE from which port in the lFB the
redirected data come. For a RedriectSource LFB, via the meta
data, CE tells FE which port in the LFB the redirected data should
go out.
Redirect Data TLV
This is a TLV describing one packet of data to be directed via the
redirect operation. The TLV format is as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = REDIRECTDATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Redirected Data |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Redirected Data: Redirected Data:
This field will make a detailed description of the data to be This field presents the whole packet that is to be redirected.
redirected as well as the data itself. The encoding of the The packet should be 32bits aligned.
description is based on the ForCES FE model if the redirector LFB
is defined by FE model, or based on vendor specifications if the
redirector LFB is defined by vendors. The description will
usually include the name (or the name ID) of the redirected packet
data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data
itself. It may also include some metadata (metadata name (or name
ID) and its value)associated with the redirected data packet.
6.9 Heartbeat Message 6.9 Heartbeat Message
The Heartbeat (HB) Message is used for one ForCES element (FE or CE) The Heartbeat (HB) Message is used for one ForCES element (FE or CE)
to asynchronously notify one or more other ForCES elements in the to asynchronously notify one or more other ForCES elements in the
same ForCES NE on its liveness. same ForCES NE on its liveness.
A Heartbeat Message is sent by a ForCES element periodically. The A Heartbeat Message is sent by a ForCES element periodically. The
time interval to send the message is set by the Association Setup 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
skipping to change at page 59, line 19 skipping to change at page 59, line 4
| Delete | | | X | X | | Delete | | | X | X |
| | | | | | | | | | | |
| Update | | | X | X | | Update | | | X | X |
| | | | | | | | | | | |
| Get | X | X | | | | Get | X | X | | |
| | | | | | | | | | | |
| Event subscribe | | | X | X | | Event subscribe | | | X | X |
| | | | | | | | | | | |
| Event unsubscribe | | | X | X | | Event unsubscribe | | | X | X |
+-------------------+-------+------------+--------+-------------+ +-------------------+-------+------------+--------+-------------+
+-----------+--------------+-------------+------------------+ +-----------+--------------+-------------+------------------+
| Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp |
+-----------+--------------+-------------+------------------+ +-----------+--------------+-------------+------------------+
| Payload | X | | | | Payload | X | | |
| | | | | | | | | |
| Event | | X | X | | Report | | X | X |
+-----------+--------------+-------------+------------------+ +-----------+--------------+-------------+------------------+
7. Protocol Scenarios 7. Protocol Scenarios
7.1 Association Setup state 7.1 Association Setup state
The associations among CEs and FEs are initiated via Association The associations among CEs and FEs are initiated via Association
setup message from the FE. If a setup request is granted by the CE, setup message from the FE. If a setup request is granted by the CE,
a successful setup response message is sent to the FE. If CEs and a successful setup response message is sent to the FE. If CEs and
FEs are operating in an insecure environment then the security FEs are operating in an insecure environment then the security
skipping to change at page 61, line 33 skipping to change at page 61, 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 63, line 4 skipping to change at page 63, line 4
|---------------------->| |---------------------->|
| | | |
| 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 65, line 30 skipping to change at page 65, 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 66, line 26 skipping to change at page 66, 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
skipping to change at page 98, line 5 skipping to change at page 98, line 5
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 F. changes between -02 and -03 Appendix F. changes between -03 and -04
1. Issue 9: changes to definiton of LFB type
2. Issue 21: removed timeliness list item since the references to
obsoleting messages was removed and it was the only content in
the section.
3. Issue 22 & 56: changed msg_Config_Repsonse message layout.
changed defintion of RESULT-TLV
4. Issue 23: closed
5. Issue 24: removed all reference to CE-LFB
6. Issue 25: closed
7. Issue 26: Replaced Teardown TLV
8. Issue 28: Added clarification of RangeMark 0xffffffff
9. Issue 30: closed
10. Issue 32: Inserted new Redirect Message text.
11. Issue 34: Added text on Priority field
12. Issue 35: Removed reference to FE TML events
13. Issue 36: Added explanation for FE and CE Failover and restart
policy
14. Issue 37: Indicated that the MAY be one and only one LFB as
opposed to MUST be one and only one.
15. Issue 38: Editorial remove forgotten editorial note.
16. Issue 41: Closed
17. Issue 44: Replaced FE, CE, and FE protocol LFB introduction with
new text.
18. Issue 45: Replaced inter-TML with explicit text
19. Issue 46: Added clarifying text on priority levels.
20. Issue 48: fixed indent editorial. Replaced SELECTOR flags with
PATH flags
21. Issue 49: Changes to Association setup message, clarify use of
SET and GET-RESPONSE
22. Issue 51: Replace Event with Report in Command summary table
23. Issue 52: Change to Association Setup message
24. Issue 55: updated text on transaction types
25. Issue 56: Added error for Assocition Setup Repsonse and Config
Response Message
Appendix G. changes between -02 and -03
1. Remove most all editorial notes and replaced them with entries in 1. Remove most all editorial notes and replaced them with entries in
tracker. tracker.
2. Marked TBD with tracker issue number 2. Marked TBD with tracker issue number
3. In section on config message replaced GET in the example figures 3. In section on config message replaced GET in the example figures
to SET to SET
4. ISSUE: 12 - replaced Command with Message type in Common Header 4. ISSUE: 12 - replaced Command with Message type in Common Header
5. ISSUE: 12 - in Data Packing Rules replaced 'sans' with 'without 5. ISSUE: 12 - in Data Packing Rules replaced 'sans' with 'without
the' the'
6. Removed an uncountably large multitude of tabs that were making 6. Removed an uncountably large multitude of tabs that were making
xml2rfc-1.29 choke xml2rfc-1.29 choke.
7. fixed many nits 7. fixed many nits
Appendix G. Changes between -01 and -02 Appendix H. Changes between -01 and -02
1. Renamed definitions.xml to Definitions.xml 1. Renamed definitions.xml to Definitions.xml
2. Added Alistair Munro to acks list. 2. Added Alistair Munro to acks list.
3. path-data additions + full BNF conformant to RFC 2234 3. path-data additions + full BNF conformant to RFC 2234
4. Appendix C with examples. #3 and #4 are the biggest changes 4. Appendix C with examples. #3 and #4 are the biggest changes
incorporate many many days of discussion. incorporate many many days of discussion.
skipping to change at page 100, line 5 skipping to change at page 102, line 5
more readable more readable
10. Rewrote the atomicity section (still under construction input 10. Rewrote the atomicity section (still under construction input
text on ACID from Robert and Alistair) text on ACID from Robert and Alistair)
11. fixed up the model reference to have all authors and added acid 11. fixed up the model reference to have all authors and added acid
reference reference
12. Weiming's updates to query and event msgs to add path-data. 12. Weiming's updates to query and event msgs to add path-data.
Appendix H. Changes between -00 and -01 Appendix I. 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
 End of changes. 

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