draft-ietf-forces-protoextension-06.txt   rfc7391.txt 
Internet Engineering Task Force J. Hadi Salim Internet Engineering Task Force (IETF) J. Hadi Salim
Internet-Draft Mojatatu Networks Request for Comments: 7391 Mojatatu Networks
Updates: 7121,5810 (if approved) September 9, 2014 Updates: 5810, 7121 October 2014
Intended status: Standards Track Category: Standards Track
Expires: March 13, 2015 ISSN: 2070-1721
ForCES Protocol Extensions Forwarding and Control Element Separation (ForCES) Protocol Extensions
draft-ietf-forces-protoextension-06
Abstract Abstract
Experience in implementing and deploying ForCES architecture has Experience in implementing and deploying the Forwarding and Control
demonstrated need for a few small extensions both to ease Element Separation (ForCES) architecture has demonstrated the need
programmability and to improve wire efficiency of some transactions. for a few small extensions both to ease programmability and to
The ForCES protocol is extended with a table range operation and a improve wire efficiency of some transactions. The ForCES protocol is
new extension for error handling. This documents updates both RFC extended with a table range operation and a new extension for error
5810 and RFC 7121 semantics to achieve that end goal. handling. This document updates the semantics in RFCs 5810 and 7121
to achieve that end goal.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on March 13, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7391.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Terminology and Conventions . . . . . . . . . . . . . . . 3 1.1. Terminology and Conventions ................................3
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 3 1.1.1. Requirements Language ...............................3
1.1.2. Definitions . . . . . . . . . . . . . . . . . . . . . 3 1.1.2. Terminology .........................................3
2. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2. Problem Overview ................................................4
2.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Table Ranges ...............................................4
2.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Error Codes ................................................4
3. Protocol Update . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Update .................................................5
3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Table Ranges ...............................................5
3.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Error Codes ................................................6
3.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. New Codes ...........................................7
3.2.2. Private Vendor Codes . . . . . . . . . . . . . . . . . 8 3.2.2. Private Vendor Codes ................................8
3.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8 3.2.3. Extended Result TLV .................................8
3.2.3.1. Extended Result Backward compatibility . . . . . . 9 3.2.3.1. Extended Result Backward Compatibility .....9
3.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 10 3.3. Large Table Dumping ........................................9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 4. IANA Considerations ............................................11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations ........................................12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. References .....................................................12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References ......................................12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References ....................................12
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. New FEPO Version ......................................13
Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 14 Acknowledgments ...................................................23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address ..................................................23
1. Introduction 1. Introduction
Experience in implementing and deploying ForCES architecture has Experience in implementing and deploying the ForCES architecture has
demonstrated need for a few small extensions both to ease demonstrated the need for a few small extensions both to ease
programmability and to improve wire efficiency of some transactions. programmability and to improve wire efficiency of some transactions.
This document describes a few extensions to the ForCES Protocol This document describes a few extensions to the semantics in the
Specification [RFC5810] semantics to achieve that end goal. ForCES protocol specification [RFC5810] to achieve that end goal.
This document describes and justifies the need for 2 small extensions This document describes and justifies the need for two small
which are backward compatible. The document also clarifies details extensions that are backward compatible. This document also
of how dumping of a large table residing on an FE (Forwarding Engine) clarifies details of how dumping of a large table residing on an FE
is achieved. To summarize: (Forwarding Element) is achieved. To summarize:
1. A table range operation to allow a controller or control 1. A table range operation to allow a controller or control
application to request an arbitrary range of table rows is application to request an arbitrary range of table rows is
introduced. introduced.
2. Additional error codes returned to the controller (or control 2. Additional error codes returned to the controller (or control
application) by an FE are introduced. Additionally a new application) by an FE are introduced. Additionally, a new
extension to carry details on error codes is introduced. As a extension to carry details on error codes is introduced. As a
result the (FE Protocol Object) FEPO LFB is updated over the result, this document updates the definition of the FE Protocol
definition in [RFC7121]. Object (FEPO) Logical Functional Block (LFB) in [RFC7121].
3. While already supported, an FE response to a GET request of a 3. While already supported, an FE response to a GET request of a
large table which does not fit in a single PL message is not large table that does not fit in a single Protocol Layer (PL)
described in [RFC5810]. This document clarifies the details. message is not described in [RFC5810]. This document clarifies
the details.
1.1. Terminology and Conventions 1.1. Terminology and Conventions
1.1.1. Requirements Language 1.1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
1.1.2. Definitions 1.1.2. Terminology
This document reiterates the terminology defined in several ForCES This document reiterates the terminology defined in several ForCES
documents [RFC3746], [RFC5810], [RFC5811], and [RFC5812] for the sake documents ([RFC3746], [RFC5810], [RFC5811], and [RFC5812]) for the
of contextual clarity. sake of contextual clarity.
Control Engine (CE) Control Element (CE)
Forwarding Element (FE)
Forwarding Engine (FE)
FE Model FE Model
LFB (Logical Functional Block) Class (or type) LFB (Logical Functional Block) Class (or type)
LFB Instance LFB Instance
LFB Model LFB Model
LFB Metadata LFB Metadata
ForCES Component ForCES Component
LFB Component LFB Component
ForCES Protocol Layer (ForCES PL) ForCES Protocol Layer (ForCES PL)
ForCES Protocol Transport Mapping Layer (ForCES TML) ForCES Protocol Transport Mapping Layer (ForCES TML)
2. Problem Overview 2. Problem Overview
In this section we present sample use cases to illustrate each In this section, we present sample use cases to illustrate each
challenge being addressed. challenge being addressed.
2.1. Table Ranges 2.1. Table Ranges
Consider, for the sake of illustration, an FE table with 1 million Consider, for the sake of illustration, an FE table with 1 million
reasonably sized table rows which are sparsely populated. Assume, reasonably sized table rows that are sparsely populated. Assume,
again for the sake of illustration, that there are 2000 table rows again for the sake of illustration, that there are 2000 table rows
sparsely populated between the row indices 23-10023. sparsely populated between the row indices 23-10023.
Implementation experience has shown that existing approaches for Implementation experience has shown that existing approaches for
retrieving or deleting a sizable number of table rows to be both retrieving or deleting a sizable number of table rows are both
programmatically tedious and inefficient on utilization of both programmatically tedious and inefficient on utilization of both
compute and wire resources. compute and wire resources.
By Definition, ForCES GET and DEL requests sent from a controller (or By definition, ForCES GET and DEL requests sent from a controller (or
control app) are prepended with a path to a component and sent to the control application) are prepended with a path to a component and
FE. In the case of indexed tables, the component path can either sent to the FE. In the case of indexed tables, the component path
point to a table or a table row index. can point to either a table or a table row index.
As an example, a control application attempting to retrieve the first As an example, a control application attempting to retrieve the first
2000 table rows appearing between row indices 23 and 10023 can 2000 table rows appearing between row indices 23 and 10023 can
achieve its goal in one of: achieve its goal in one of the following ways:
o Dump the whole table and filter for the needed 2000 table rows. o Dump the whole table and filter for the needed 2000 table rows.
o Send upto 10000 ForCES PL requests, incrementing the index by one o Send up to 10000 ForCES PL requests, incrementing the index by one
each time, and stop when the needed 2000 entries are retrieved. each time, and stop when the needed 2000 entries are retrieved.
o If the application had knowledge of which table rows existed (not o If the application had knowledge of which table rows existed (not
unreasonable given the controller is supposed to be aware of state unreasonable given the controller is supposed to be aware of state
within an NE), then the application could take advantage of ForCES within a Network Element (NE)), then the application could take
batching to send fewer large messages (each with different path advantage of ForCES batching to send fewer large messages (each
entries for a total of two thousand). with different path entries for a total of 2000).
As argued, while the above options exist, all are tedious. As argued, while the above options exist, all are tedious.
2.2. Error codes 2.2. Error Codes
[RFC5810] has defined a generic set of error codes that are to be [RFC5810] has defined a generic set of error codes that are to be
returned to the CE from an FE. Deployment experience has shown that returned to the CE from an FE. Deployment experience has shown that
it would be useful to have more fine grained error codes. As an it would be useful to have more fine-grained error codes. As an
example, the error code E_NOT_SUPPORTED could be mapped to many FE example, the error code E_NOT_SUPPORTED could be mapped to many FE
error source possibilities that need to be then interpreted by the error source possibilities that need to then be interpreted by the
caller based on some understanding of the nature of the sent request. caller based on some understanding of the nature of the sent request.
This makes debugging more time consuming. This makes debugging more time consuming.
3. Protocol Update 3. Protocol Update
This section describes normative update to the ForCES protocol for This section describes a normative update to the ForCES protocol to
issues discussed in Section 2. address the issues discussed in Section 2.
3.1. Table Ranges 3.1. Table Ranges
We define a new TLV, TABLERANGE-TLV (type ID 0x117) that will be We define a new TLV, TABLERANGE-TLV (type ID 0x0117), that will be
associated with the PATH-DATA TLV in the same manner the KEYINFO-TLV associated with the PATH-DATA-TLV in the same manner the KEYINFO-TLV
is. is. Figure 1 shows how this new TLV is constructed.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x117) | Length | | Type (0x0117) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Index | | Start Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Index | | End Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ForCES table range request Layout Figure 1: ForCES Table Range Request Layout
Figure 1 shows how this new TLV is constructed. Figure 2 illustrates a GET request for a range of rows 11 to 23 of a
table with a component path of "1/6".
OPER = GET OPER = GET-TLV
PATH-DATA: PATH-DATA-TLV:
flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6}
TABLERANGE-TLV content = {11,23} TABLERANGE-TLV content = {11,23}
Figure 2: ForCES table range request Figure 2: ForCES Table Range Request Example
Figure 2 illustrates a GET request for a range of rows 11 to 23 of a
table with component path of "1/6".
Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as The path flag F_SELTABRANGE (0x2, i.e., bit 1, where bit 0 is
defined in RFC 5810) MUST be set to indicate the presence of the F_SELKEY as defined in [RFC5810]) MUST be set to indicate the
TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a presence of the TABLERANGE-TLV. The path flag bit F_SELTABRANGE can
GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST only be used in a GET or DEL and is mutually exclusive with F_SELKEY.
enforce the path flag constraints and ensure that the selected path The FE MUST enforce the path flag constraints and ensure that the
belongs to a defined indexed table component. Any violation of these selected path belongs to a defined, indexed table component. Any
constraints MUST be rejected with an error code of E_INVALID_TFLAGS violation of these constraints MUST be rejected with an error code of
with a description of what the problem is when using extended error E_INVALID_TFLAGS with a description of what the problem is when using
reporting (refer to Section 3.2). extended error reporting (refer to Section 3.2).
It should be noted that there are combination of path selection It should be noted that there are combinations of path selection
mechanisms that should not appear together for the sake of simplicity mechanisms that should not appear together for the sake of simplicity
of operations. These include: TABLERANGE-TLV and KEYINFO-TLV as well of operations. These include TABLERANGE-TLV and KEYINFO-TLV as well
as multiple nested TABLERANGE-TLVs. as multiple nested TABLERANGE-TLVs.
The TABLERANGE-TLV contents constitute: The TABLERANGE-TLV contents constitute:
o A 32 bit start index. An index of 0 implies the beginning of the o A 32-bit start index. An index of 0 implies the beginning of the
table row. table row.
o A 32 bit end index. A value of 0xFFFFFFFF implies the last entry. o A 32-bit end index. A value of 0xFFFFFFFF implies the last entry.
The response for a table range query will either be: The response for a table range query will either be:
o The requested table data returned (when at least one referenced o The requested table data returned (when at least one referenced
row is available); in such a case, a response with a path pointing row is available); in such a case, a response with a path pointing
to the table and whose data content contains the row(s) will be to the table and whose data content contains the row(s) will be
sent to the CE. The data content MUST be encapsulated in sent to the CE. The data content MUST be encapsulated in a
sparsedata TLV. The sparse data TLV content will have the "I" (in SPARSEDATA-TLV. The SPARSEDATA-TLV content will have the "I" (in
ILV) for each table row indicating the table indices. Index-Length-Value (ILV)) for each table row indicating the table
indices.
o An EXTENDEDRESULT-TLV (refer to Section 3.2.3) when: o An EXTENDEDRESULT-TLV (refer to Section 3.2.3) when:
* Response is to a range delete request. The Result will either * the response is to a range delete request. The result will
be: either be:
+ A success if any of the requested-for rows is deleted + a success if any of the rows that were requested are
+ A proper error code if none of the requested for rows can be deleted; or
deleted
* data is absent where the result code of E_EMPTY with an + a proper error code if none of the rows that were requested
optional content string describing the nature of the error can be deleted.
(refer to Section 3.2).
* When both a path key and path table range are reflected on the * data is absent and an error code of E_EMPTY with an optional
the pathflags, an error code of E_INVALID_TFLAGS with an content string describing the nature of the error is used
optional content string describing the nature of the error
(refer to Section 3.2). (refer to Section 3.2).
* other standard ForCES errors (such as ACL constraints trying to * both a path key and path table range were stated on the path
retrieve contents of an unreadable table), accessing unknown flags of the original request. In such a case, an error code
components etc. of E_INVALID_TFLAGS with an optional content string describing
the nature of the error is used (refer to Section 3.2).
* other standard ForCES errors (such as Access Control List (ACL)
constraints trying to retrieve contents of an unreadable table,
accessing unknown components, etc.) occur.
3.2. Error Codes 3.2. Error Codes
We define several things: We define the following:
1. A new set of error codes. 1. A new set of error codes.
2. Allocating some reserved codes for private use. 2. Allocation of some reserved codes for private use.
3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code 3. A new TLV, EXTENDEDRESULT-TLV (0x0118), that will carry a code
(which will be a superset of what is currently specified in (which will be a superset of what is currently specified in
[RFC5810]) but also an optional cause content. This is [RFC5810]) as well as an optional cause content. This is
illustrated in Figure 3. illustrated in Figure 3.
3.2.1. New Codes 3.2.1. New Codes
EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC The EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of
5810 Result TLV Result Value. The new version code space is 32 bits the RESULT-TLV Result Value defined in [RFC5810]. The new version
as opposed to the RFC 5810 code size of 8 bits. The first 8 bit code space is 32 bits as opposed to the code size of 8 bits in
values(256 codes) are common to both code spaces. [RFC5810]. The first 8-bit values (256 codes) are common to both
code spaces.
+------------+-------------------------+----------------------------+ +------------+-------------------------+----------------------------+
| Code | Mnemonic | Details | | Code | Mnemonic | Details |
+------------+-------------------------+----------------------------+ +------------+-------------------------+----------------------------+
| 0x18 | E_TIMED_OUT | A time out occured while | | 0x18 | E_TIMED_OUT | A timeout occurred while |
| | | processing the message | | | | processing the message |
| | | |
| 0x19 | E_INVALID_TFLAGS | Invalid table flags | | 0x19 | E_INVALID_TFLAGS | Invalid table flags |
| | | |
| 0x1A | E_INVALID_OP | Requested operation is | | 0x1A | E_INVALID_OP | Requested operation is |
| | | invalid | | | | invalid |
| 0x1B | E_CONGEST_NT | Node Congestion | | | | |
| 0x1B | E_CONGEST_NT | Node congestion |
| | | notification | | | | notification |
| | | |
| 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table | | 0x1C | E_COMPONENT_NOT_A_TABLE | Component not a table |
| | | |
| 0x1D | E_PERM | Operation not permitted | | 0x1D | E_PERM | Operation not permitted |
| 0x1E | E_BUSY | System is Busy | | | | |
| 0x1E | E_BUSY | System is busy |
| | | |
| 0x1F | E_EMPTY | Table is empty | | 0x1F | E_EMPTY | Table is empty |
| 0x20 | E_UNKNOWN | A generic catch all error | | | | |
| | | code. Carries a string to | | 0x20 | E_UNKNOWN | A generic catch-all error |
| | | code. Carries a string to |
| | | further extrapolate what | | | | further extrapolate what |
| | | the error implies. | | | | the error implies. |
+------------+-------------------------+----------------------------+ +------------+-------------------------+----------------------------+
Table 1: New codes Table 1: New Codes
3.2.2. Private Vendor Codes 3.2.2. Private Vendor Codes
Codes 0x100-0x200 are reserved for use as private codes. Since these Codes 0x100-0x200 are reserved for use as private codes. Since these
are freely available it is expected that the FE and CE side are freely available, it is expected that the FE and CE side
implementations will both understand/interpret the semantics of any implementations will both understand/interpret the semantics of any
used codes and avoid any conflicts. used codes and avoid any conflicts.
3.2.3. Extended Result TLV 3.2.3. Extended Result TLV
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = EXTENDEDRESULT-TLV | Length | | Type = EXTENDEDRESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | | Result Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Cause content | | Optional Cause Content |
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EXTENDEDRESULT-TLV Figure 3: EXTENDEDRESULT-TLV
o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to
be 32 bit aligned. be 32-bit aligned.
o The EXTENDEDRESULT-TLV Result Value derives and extends from the o The EXTENDEDRESULT-TLV Result Value derives and extends from the
same current namespace that is used by RESULT-TLV Result Value as same current namespace that is used by the RESULT-TLV Result Value
specified in RFC 5810, section 7.1.7. The main difference is that as specified in Section 7.1.7 of [RFC5810]. The main difference
we now have a 32 bit result value (as opposed to old 8 bit). is that there is now a 32-bit Result Value (as opposed to the old
8-bit).
o The optional result content is defined to further disambiguate the o The Optional Cause Content is defined to further disambiguate the
result value. It is expected UTF-8 string values to be used. The Result Value. It is expected that UTF-8 string values will be
content result value is intended to be consumed by the (human) used. The content Result Value is intended to be consumed by the
operator and implementations may choose to specify different (human) operator, and implementations may choose to specify
contents for the same error code. Additionally, future codes may different content for the same error code. Additionally, future
specify cause contents to be of types other than string. codes may specify cause content to be of types other than string.
o It is recommended that the maximum size of the cause string should o It is recommended that the maximum size of the cause string should
not exceed 32 bytes. The cause string is not standardized by this not exceed 32 bytes. The cause string is not standardized by this
document. document.
3.2.3.1. Extended Result Backward compatibility 3.2.3.1. Extended Result Backward Compatibility
To support backward compatibility, we update and the FEPO LFB (in To support backward compatibility, we update the FEPO LFB (in
Appendix A) version to 1.2. We also add a new component ID 16 (named Appendix A) to version 1.2. We also add a new component ID 16 (named
EResultAdmin) and a capability Component ID 32 (named EResultCapab). EResultAdmin), and a capability component ID 32 (named EResultCapab).
An FE will advertise its capability to support extended TLVs via the An FE will advertise its capability to support extended TLVs via the
EResultCapab table. When an FE is capable of responding with both EResultCapab table. When an FE is capable of responding with both
extended results and older result TLVs, it will have two table rows extended results and older result TLVs, it will have two table rows,
one for each supported value. By default an FE capable of supporting one for each supported value. By default, an FE capable of
both modes will assume the lowest common denominator i.e EResultAdmin supporting both modes will assume the lowest common denominator
will be EResultNotSupported; and will issue responses using RESULT- (i.e., EResultAdmin will be EResultNotSupported) and will issue
TLVs. It should be noted an FE advertising FEPO version 1.2 MUST responses using RESULT-TLVs. It should be noted that an FE
support EXTENDEDRESULT-TLVs at minimum. advertising FEPO version 1.2 MUST support EXTENDEDRESULT-TLVs at
minimum.
On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a On an FE that supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a
master CE can turn on support for extended results by setting the master CE can turn on support for extended results by setting the
EResultAdmin value to 2 in which case the FE MUST switch over to EResultAdmin value to 2, in which case the FE MUST switch over to
sending only EXTENDEDRESULT-TLVs. Likewise a master CE can turn off sending only EXTENDEDRESULT-TLVs. Likewise, a master CE can turn off
extended result responses by writing a 1 to the EResultAdmin. An FE extended result responses by writing a 1 to the EResultAdmin. An FE
that does not support one mode or other MUST reject setting of that does not support one mode or the other MUST reject setting
EResultAdmin to a value it does not support by responding with an EResultAdmin to a value it does not support by responding with an
error code of E_NOT_SUPPORTED. It is expected that all CEs error code of E_NOT_SUPPORTED. It is expected that all CEs
participating in a high availability(HA) mode be capable of participating in a high availability (HA) mode be capable of
supporting FEPO version 1.2 whenever EResultAdmin is set to strict supporting FEPO version 1.2 whenever EResultAdmin is set to strict
support of EXTENDEDRESULT-TLVs. The consensus between CEs in an HA support of EXTENDEDRESULT-TLVs. The consensus between CEs in an HA
setup to set strict support of EXTENDEDRESULT-TLVs is out of scope set up to set strict support of EXTENDEDRESULT-TLVs is out of scope
for this document. for this document.
3.3. Large Table Dumping 3.3. Large Table Dumping
Imagine a GET request to a path that is a table i.e a table dump. Imagine a GET request to a path that is a table, i.e., a table dump.
Such a request is sent to the FE with a specific correlator, say X. Such a request is sent to the FE with a specific correlator, say X.
Imagine this table to have a large number of entries at the FE. For Imagine this table to have a large number of entries at the FE. For
the sake of illustration, lets say millions of rows. This requires the sake of illustration, let's say millions of rows. This requires
that the FE delivers the response over multiple messages, all using that the FE delivers the response over multiple messages, all using
the same correlator X. the same correlator X.
The protocol document [RFC5810] does not adequately describe how a The ForCES protocol document [RFC5810] does not adequately describe
large multi-part GET response message is delivered. The text in this how a large multi-part GET response message is delivered; the text in
section clarifies. We limit the discussion to a table object only. this section clarifies. We limit the discussion to a table object
only.
Implementation experience of dumping large tables indicates we can
use the transaction flags to indicate that a GET response is the
beginning, middle or end of a multi-part message. In other words we
mirror the effect of an atomic transaction sent by a CE to an FE.
CE PL FE PL
| |
| (0) Query, Path-to-a-large-table, OP=GET |
|----------------------------------------------------->|
| correlator = X |
| |
| (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
. .
. .
. .
. .
| |
| (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (N) Query-Response, EOT,AT, OP=GET-RESPONSE |
|<-----------------------------------------------------|
| correlator = X |
| RESULT TLV (SUCCESS) |
| |
Figure 4: EXTENDEDRESULT-TLV
The last message to go to the CE, which carries the EOT flag, MUST Implementation experience of dumping large tables shows that we can
NOT carry any data. This allows us to mirror ForCES 2PC messaging use transaction flags to indicate that a GET response is the
[RFC5810] where the last message is an empty commit message. GET beginning, middle, or end of a multi-part message. In other words,
response will carry a result code TLV in such a case. we mirror the effect of an atomic transaction sent by a CE to an FE.
4. Acknowledgements CE PL FE PL
The author would like to thank Evangelos Haleplidis and Joel Halpern | |
for discussions that made this document better. Adrian Farrel did an | (0) Query, Path-to-a-large-table, OP=GET |
excellent AD review of the document which improved the quality of |----------------------------------------------------->|
this document. Tobias Gondrom did the Security Directorate review. | correlator = X |
Brian Carpenter did the Gen-ART review. Nevil Brownlee performed the | |
Operations Directorate review. S Moonesamy(SM) worked hard to review | (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA |
our publication process. Pearl Liang caught issues in the IANA |<-----------------------------------------------------|
specification. | correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
. .
. .
. .
. .
| |
| (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------|
| correlator = X |
| DATA TLV (SPARSE/FULL) |
| |
| (N) Query-Response, EOT,AT, OP=GET-RESPONSE |
|<-----------------------------------------------------|
| correlator = X |
| RESULT-TLV (SUCCESS) |
| |
The author would like to thank the following IESG members who Figure 4: Large Table Dump Time Sequence
reviewed and improved this document: Alia Atlas, Barry Leiba, Brian
Haberman, Kathleen Moriarty, Richard Barnes, and Spencer Dawkins.
5. IANA Considerations The last message to go to the CE, which carries the End Of
Transaction (EOT) flag, MUST NOT carry any data. This allows us to
mirror ForCES two-phase commit (2PC) messaging [RFC5810] where the
last message is an empty commit message. A GET response will carry a
RESULT-TLV in such a case.
This document registers two new top Level TLVs and two new path flags 4. IANA Considerations
and updates an IANA registered FE Protocol object Logical Functional
Block (LFB).
The Appendix A defines an update to the FE Protocol Object LFB to This document updates <https://www.iana.org/assignments/forces>
version 1.2. The IANA registry as follows:
https://www.iana.org/assignments/forces sub-registy "Logical
Functional Block (LFB) Class Names and Class Identifiers" will need
to be append for FE Protocol Object LFB version 1.2 and this document
reflected in the reference column.
Updates are required to the "TLV types" subregistry for the TLVs This document registers two new top-level TLVs and two new path
below. flags; it also updates an IANA-registered FE Protocol Object Logical
Functional Block (LFB).
The following new TLVs are defined: Appendix A defines an update to the FE Protocol Object LFB to
version 1.2. An entry for FE Protocol Object LFB version 1.2 has
been added to the "Logical Functional Block (LFB) Class Names and
Class Identifiers" sub-registry.
o TABLERANGE-TLV (type ID 0x117) The following new TLVs have been defined and added to the "TLV Types"
sub-registry:
o EXTENDEDRESULT-TLV (type ID 0x118) o TABLERANGE-TLV (type ID 0x0117)
subregistry "RESULT-TLV Result Values" is affected by the entries o EXTENDEDRESULT-TLV (type ID 0x0118)
below.
The Defined RESULT-TLV Result Values are changed: The "RESULT-TLV Result Values" sub-registry has been updated
as follows:
o codes 0x21-0xFE are unassigned. o Codes 0x21-0xFE are marked as Unassigned.
o codes 0x18-0x20 are defined by this document in Section 3.2.1. o Codes 0x18-0x20 are defined by this document in Section 3.2.1.
o codes 0x100-0x200 are reserved for private use. o Codes 0x100-0x200 are reserved for private use.
A new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be A new "EXTENDEDRESULT-TLV Result Values" sub-registry has been
created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result created. The codes 0x00-0xFF are mirrored from the "RESULT-TLV
Values sub-registry. Any new allocations of this code range (in the Result Values" sub-registry. Any future allocations of this code
range 0x21-0xfe) must happen only within the new sub-registry and not range (in the range 0x21-0xFE) must be made only in the new
in RESULT-TLV Result Values sub-registry. The codes 0x100-0x200 are "EXTENDEDRESULT-TLV Result Values" sub-registry and not in the
reserved for private use as described earlier and the code ranges "RESULT-TLV Result Values" sub-registry. The codes 0x100-0x200 are
0x21-0xfe and 0x201-0xffffffff should be marked as Unassigned with reserved for private use as described earlier, and the code ranges
the IANA allocation policy of Specification Required [RFC5226]. The 0x21-0xFE and 0x201-0xFFFFFFFF are marked as Unassigned with the IANA
Designated Expert (DE) needs to ensure existing deployments are not allocation policy of Specification Required [RFC5226]. The
broken by any specified request. The DE should post a given code Designated Expert (DE) needs to ensure that existing deployments are
not broken by any specified request. The DE should post a given code
request to the ForCES WG mailing list (or a successor designated by request to the ForCES WG mailing list (or a successor designated by
the Area Director) for any comment and review. The DE should then the Area Director) for comment and review. The DE should then either
either approve or deny the registration request, publish a notice of approve or deny the registration request, publish a notice of the
the decision to the ForCES WG mailing list or its successor, and decision to the ForCES WG mailing list or its successor, and inform
inform IANA of his/her decision. A denial notice must be justified IANA of his/her decision. A denial notice must be justified by an
by an explanation and, in the cases where it is possible, concrete explanation and, in the cases where it is possible, concrete
suggestions on how the request can be modified so as to become suggestions on how the request can be modified so as to become
acceptable. acceptable.
6. Security Considerations 5. Security Considerations
The security considerations that have been described in the ForCES The security considerations described in the ForCES protocol
protocol [RFC5810] apply to this document as well. [RFC5810] apply to this document as well.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
Control Element Separation (ForCES) Protocol Control Element Separation (ForCES) Protocol
Specification", RFC 5810, March 2010. Specification", RFC 5810, March 2010,
<http://www.rfc-editor.org/info/rfc5810>.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping
Layer (TML) for the Forwarding and Control Element Layer (TML) for the Forwarding and Control Element
Separation (ForCES) Protocol", RFC 5811, March 2010. Separation (ForCES) Protocol", RFC 5811, March 2010,
<http://www.rfc-editor.org/info/rfc5811>.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model", Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010. RFC 5812, March 2010, <http://www.rfc-editor.org/
info/rfc5812>.
[RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim, [RFC7121] Ogawa, K., Wang, W., Haleplidis, E., and J. Hadi Salim,
"High Availability within a Forwarding and Control Element "High Availability within a Forwarding and Control Element
Separation (ForCES) Network Element", RFC 7121, Separation (ForCES) Network Element", RFC 7121,
February 2014. February 2014, <http://www.rfc-editor.org/info/rfc7121>.
7.2. Informative References 6.2. Informative References
[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,
<http://www.rfc-editor.org/info/rfc3746>.
Appendix A. Appendix A - New FEPO version Appendix A. New FEPO Version
This version of FEPO updates the earlier one given in RFC 7121. The This version of FEPO updates the earlier one given in [RFC7121]. The
xml has been validated against the schema defined in [RFC5812]. XML has been validated against the schema defined in [RFC5812].
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="lfb-schema.xsd" provides="FEPO"> xsi:noNamespaceSchemaLocation="lfb-schema.xsd" provides="FEPO">
<!-- XXX --> <!-- XXX -->
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>CEHBPolicyValues</name> <name>CEHBPolicyValues</name>
<synopsis> <synopsis>
The possible values of CE heartbeat policy The possible values of CE heartbeat policy
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>CEHBPolicy0</name> <name>CEHBPolicy0</name>
<synopsis> <synopsis>
The CE will send heartbeats to the FE The CE will send heartbeats to the FE
every CEHDI timeout if no other messages every CEHDI timeout if no other messages
have been sent since. have been sent since.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>CEHBPolicy1</name> <name>CEHBPolicy1</name>
<synopsis> <synopsis>
The CE will not send heartbeats to the FE The CE will not send heartbeats to the FE.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEHBPolicyValues</name> <name>FEHBPolicyValues</name>
<synopsis> <synopsis>
The possible values of FE heartbeat policy The possible values of FE heartbeat policy
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>FEHBPolicy0</name> <name>FEHBPolicy0</name>
<synopsis> <synopsis>
The FE will not generate any heartbeats The FE will not generate any heartbeats to the CE.
to the CE </synopsis>
</synopsis>
</specialValue>
<specialValue value="1">
<name>FEHBPolicy1</name>
<synopsis>
The FE generates heartbeats to the CE every FEHI
if no other messages have been sent to the CE.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>FERestartPolicyValues</name>
<synopsis>
The possible values of FE restart policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>FERestartPolicy0</name>
<synopsis>
The FE restarts its state from scratch
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>HAModeValues</name>
<synopsis>
The possible values of HA modes
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>NoHA</name>
<synopsis>
The FE is not running in HA mode
</synopsis>
</specialValue>
<specialValue value="1">
<name>ColdStandby</name>
<synopsis>
The FE is running in HA mode cold Standby
</synopsis>
</specialValue>
<specialValue value="2">
<name>HotStandby</name>
<synopsis>
The FE is running in HA mode hot Standby
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>CEFailoverPolicyValues</name>
<synopsis>
The possible values of CE failover policy
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>CEFailoverPolicy0</name>
<synopsis>
The FE should stop functioning immediate and
transition to the FE OperDisable state
</synopsis>
</specialValue>
<specialValue value="1">
<name>CEFailoverPolicy1</name>
<synopsis>
The FE should continue forwarding even
without an associated CE for CEFTI. The
FE goes to FE OperDisable when the CEFTI
expires and no association. Requires
graceful restart support.
</synopsis>
</specialValue>
</specialValues> </specialValue>
</atomic> <specialValue value="1">
</dataTypeDef> <name>FEHBPolicy1</name>
<dataTypeDef> <synopsis>
<name>FEHACapab</name> The FE generates heartbeats to the CE every
<synopsis> FEHI if no other
The supported HA features messages have been sent to the CE.
</synopsis> </synopsis>
<atomic> </specialValue>
<baseType>uchar</baseType> </specialValues>
<specialValues> </atomic>
<specialValue value="0"> </dataTypeDef>
<name>GracefullRestart</name> <dataTypeDef>
<synopsis> <name>FERestartPolicyValues</name>
The FE supports Graceful Restart <synopsis>
</synopsis> The possible values of FE restart policy
</specialValue> </synopsis>
<specialValue value="1"> <atomic>
<name>HA</name> <baseType>uchar</baseType>
<synopsis> <specialValues>
The FE supports HA <specialValue value="0">
</synopsis> <name>FERestartPolicy0</name>
</specialValue> <synopsis>
</specialValues> The FE restarts its state from scratch.
</atomic> </synopsis>
</dataTypeDef> </specialValue>
<dataTypeDef> </specialValues>
<name>CEStatusType</name> </atomic>
<synopsis>Status values. Status for each CE</synopsis> </dataTypeDef>
<atomic> <dataTypeDef>
<baseType>uchar</baseType> <name>HAModeValues</name>
<specialValues> <synopsis>
<specialValue value="0"> The possible values of HA modes
<name>Disconnected</name> </synopsis>
<synopsis>No connection attempt with the CE yet <atomic>
</synopsis> <baseType>uchar</baseType>
</specialValue> <specialValues>
<specialValue value="1"> <specialValue value="0">
<name>Connected</name> <name>NoHA</name>
<synopsis>The FE connection with the CE at the TML <synopsis>
has been completed The FE is not running in HA mode.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="1">
<name>Associated</name> <name>ColdStandby</name>
<synopsis>The FE has associated with the CE <synopsis>
</synopsis> The FE is running in HA mode cold standby.
</specialValue> </synopsis>
<specialValue value="3">
<name>IsMaster</name>
<synopsis>The CE is the master (and associated)
</synopsis>
</specialValue>
<specialValue value="4">
<name>LostConnection</name>
<synopsis>The FE was associated with the CE but
lost the connection
</synopsis>
</specialValue>
<specialValue value="5">
<name>Unreachable</name>
<synopsis>The CE is deemed as unreachable by the FE
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>StatisticsType</name>
<synopsis>Statistics Definition</synopsis>
<struct>
<component componentID="1">
<name>RecvPackets</name>
<synopsis>Packets Received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>RecvErrPackets</name>
<synopsis>Packets Received from CE with errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>RecvBytes</name>
<synopsis>Bytes Received from CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>RecvErrBytes</name>
<synopsis>Bytes Received from CE in Error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>TxmitPackets</name>
<synopsis>Packets Transmitted to CE</synopsis>
<typeRef>uint64</typeRef>
</component> </specialValue>
<component componentID="6"> <specialValue value="2">
<name>TxmitErrPackets</name> <name>HotStandby</name>
<synopsis> <synopsis>
Packets Transmitted to CE that incurred The FE is running in HA mode hot standby.
errors </synopsis>
</synopsis> </specialValue>
<typeRef>uint64</typeRef> </specialValues>
</component> </atomic>
<component componentID="7"> </dataTypeDef>
<name>TxmitBytes</name> <dataTypeDef>
<synopsis>Bytes Transmitted to CE</synopsis> <name>CEFailoverPolicyValues</name>
<typeRef>uint64</typeRef> <synopsis>
</component> The possible values of CE failover policy
<component componentID="8"> </synopsis>
<name>TxmitErrBytes</name> <atomic>
<synopsis>Bytes Transmitted to CE incurring errors <baseType>uchar</baseType>
</synopsis> <specialValues>
<typeRef>uint64</typeRef> <specialValue value="0">
</component> <name>CEFailoverPolicy0</name>
</struct> <synopsis>
</dataTypeDef> The FE should stop functioning immediately
<dataTypeDef> and transition to FE OperDisable state.
<name>AllCEType</name> </synopsis>
<synopsis>Table Type for AllCE component</synopsis> </specialValue>
<struct> <specialValue value="1">
<component componentID="1"> <name>CEFailoverPolicy1</name>
<name>CEID</name> <synopsis>
<synopsis>ID of the CE</synopsis> The FE should continue forwarding even
<typeRef>uint32</typeRef> without an associated CE for CEFTI. The
</component> FE goes to FE OperDisable when the CEFTI
<component componentID="2"> expires and there is no association. Requires
<name>Statistics</name> graceful restart support.
<synopsis>Statistics per CE</synopsis> </synopsis>
<typeRef>StatisticsType</typeRef> </specialValue>
</component> </specialValues>
<component componentID="3"> </atomic>
<name>CEStatus</name> </dataTypeDef>
<synopsis>Status of the CE</synopsis> <dataTypeDef>
<typeRef>CEStatusType</typeRef> <name>FEHACapab</name>
</component> <synopsis>
</struct> The supported HA features
</dataTypeDef> </synopsis>
<dataTypeDef> <atomic>
<name>ExtendedResultType</name> <baseType>uchar</baseType>
<synopsis> <specialValues>
Possible extended result support <specialValue value="0">
</synopsis> <name>GracefullRestart</name>
<atomic> <synopsis>
<baseType>uchar</baseType> The FE supports graceful restart.
<rangeRestriction> </synopsis>
<allowedRange min="1" max="2"/> </specialValue>
</rangeRestriction> <specialValue value="1">
<specialValues> <name>HA</name>
<specialValue value="1"> <synopsis>
<name>EResultNotSupported</name> The FE supports HA.
<synopsis> </synopsis>
Extended Results are not supported </specialValue>
</synopsis> </specialValues>
</specialValue> </atomic>
<specialValue value="2"> </dataTypeDef>
<name>EResultSupported</name> <dataTypeDef>
<synopsis> <name>CEStatusType</name>
Extended Results are supported <synopsis>Status values. Status for each CE</synopsis>
</synopsis> <atomic>
</specialValue> <baseType>uchar</baseType>
</specialValues> <specialValues>
</atomic> <specialValue value="0">
</dataTypeDef> <name>Disconnected</name>
</dataTypeDefs> <synopsis>No connection attempt with the CE yet
<LFBClassDefs> </synopsis>
<LFBClassDef LFBClassID="2"> </specialValue>
<name>FEPO</name> <specialValue value="1">
<synopsis> <name>Connected</name>
The FE Protocol Object, with EXtended Result control <synopsis>The FE connection with the CE at the TML
</synopsis> has been completed.
<version>1.2</version> </synopsis>
<components> </specialValue>
<component componentID="1" access="read-only"> <specialValue value="2">
<name>CurrentRunningVersion</name> <name>Associated</name>
<synopsis>Currently running ForCES version</synopsis> <synopsis>The FE has associated with the CE.
<typeRef>uchar</typeRef> </synopsis>
</component> </specialValue>
<component componentID="2" access="read-only"> <specialValue value="3">
<name>FEID</name> <name>IsMaster</name>
<synopsis>Unicast FEID</synopsis> <synopsis>The CE is the master (and associated).
<typeRef>uint32</typeRef> </synopsis>
</component> </specialValue>
<component componentID="3" access="read-write"> <specialValue value="4">
<name>MulticastFEIDs</name> <name>LostConnection</name>
<synopsis> <synopsis>The FE was associated with the CE but
the table of all multicast IDs lost the connection.
</synopsis> </synopsis>
<array type="variable-size"> </specialValue>
<typeRef>uint32</typeRef> <specialValue value="5">
</array> <name>Unreachable</name>
<synopsis>The CE is deemed as unreachable by the FE.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>StatisticsType</name>
<synopsis>Statistics Definition</synopsis>
<struct>
<component componentID="1">
<name>RecvPackets</name>
<synopsis>Packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>RecvErrPackets</name>
<synopsis>Packets received from CE with errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>RecvBytes</name>
<synopsis>Bytes received from CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>RecvErrBytes</name>
<synopsis>Bytes received from CE in error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>TxmitPackets</name>
<synopsis>Packets transmitted to CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>TxmitErrPackets</name>
<synopsis>
Packets transmitted to CE that incurred
errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>TxmitBytes</name>
<synopsis>Bytes transmitted to CE</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>TxmitErrBytes</name>
<synopsis>Bytes transmitted to CE incurring errors
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>AllCEType</name>
<synopsis>Table Type for AllCE component</synopsis>
<struct>
<component componentID="1">
<name>CEID</name>
<synopsis>ID of the CE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>Statistics</name>
<synopsis>Statistics per CE</synopsis>
<typeRef>StatisticsType</typeRef>
</component>
<component componentID="3">
<name>CEStatus</name>
<synopsis>Status of the CE</synopsis>
<typeRef>CEStatusType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>ExtendedResultType</name>
<synopsis>
Possible extended result support
</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="1" max="2"/>
</rangeRestriction>
<specialValues>
<specialValue value="1">
<name>EResultNotSupported</name>
<synopsis>
Extended results are not supported.
</synopsis>
</specialValue>
<specialValue value="2">
<name>EResultSupported</name>
<synopsis>
Extended results are supported.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="2">
<name>FEPO</name>
<synopsis>
The FE Protocol Object, with extended result control
</synopsis>
<version>1.2</version>
<components>
<component componentID="1" access="read-only">
<name>CurrentRunningVersion</name>
<synopsis>Currently running ForCES version</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="2" access="read-only">
<name>FEID</name>
<synopsis>Unicast FEID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>MulticastFEIDs</name>
<synopsis>
The table of all multicast IDs
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="4" access="read-write">
<name>CEHBPolicy</name>
<synopsis>
The CE Heartbeat Policy
</synopsis>
<typeRef>CEHBPolicyValues</typeRef>
</component>
<component componentID="5" access="read-write">
<name>CEHDI</name>
<synopsis>
The CE Heartbeat Dead Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="6" access="read-write">
<name>FEHBPolicy</name>
<synopsis>
The FE Heartbeat Policy
</synopsis>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the
primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in milliseconds
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The Primary CE this FE was last associated
with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="14" access="read-write">
<name>HAMode</name>
<synopsis>
The HA mode used
</synopsis>
<typeRef>HAModeValues</typeRef>
</component>
<component componentID="15" access="read-only">
<name>AllCEs</name>
<synopsis>The table of all CEs</synopsis>
<array type="variable-size">
<typeRef>AllCEType</typeRef>
</array>
</component> </component>
<component componentID="4" access="read-write"> <component componentID="16" access="read-write">
<name>CEHBPolicy</name> <name>EResultAdmin</name>
<synopsis> <synopsis>
The CE Heartbeat Policy Turn extended results off or on,
</synopsis> but default to off.
<typeRef>CEHBPolicyValues</typeRef> </synopsis>
</component> <typeRef>ExtendedResultType</typeRef>
<component componentID="5" access="read-write"> <defaultValue>1</defaultValue>
<name>CEHDI</name> </component>
<synopsis> </components>
The CE Heartbeat Dead Interval in millisecs <capabilities>
</synopsis> <capability componentID="30">
<typeRef>uint32</typeRef> <name>SupportableVersions</name>
</component> <synopsis>
<component componentID="6" access="read-write"> The table of ForCES versions that FE supports
<name>FEHBPolicy</name> </synopsis>
<synopsis> <array type="variable-size">
The FE Heartbeat Policy <typeRef>uchar</typeRef>
</synopsis> </array>
<typeRef>FEHBPolicyValues</typeRef>
</component>
<component componentID="7" access="read-write">
<name>FEHI</name>
<synopsis>
The FE Heartbeat Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8" access="read-write">
<name>CEID</name>
<synopsis>
The Primary CE this FE is associated with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="9" access="read-write">
<name>BackupCEs</name>
<synopsis>
The table of all backup CEs other than the
primary
</synopsis>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
<component componentID="10" access="read-write">
<name>CEFailoverPolicy</name>
<synopsis>
The CE Failover Policy
</synopsis>
<typeRef>CEFailoverPolicyValues</typeRef>
</component>
<component componentID="11" access="read-write">
<name>CEFTI</name>
<synopsis>
The CE Failover Timeout Interval in millisecs
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="12" access="read-write">
<name>FERestartPolicy</name>
<synopsis>
The FE Restart Policy
</synopsis>
<typeRef>FERestartPolicyValues</typeRef>
</component>
<component componentID="13" access="read-write">
<name>LastCEID</name>
<synopsis>
The Primary CE this FE was last associated
with
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="14" access="read-write">
<name>HAMode</name>
<synopsis>
The HA mode used
</synopsis>
<typeRef>HAModeValues</typeRef>
</component>
<component componentID="15" access="read-only">
<name>AllCEs</name>
<synopsis>The table of all CEs</synopsis>
<array type="variable-size">
<typeRef>AllCEType</typeRef>
</array>
</component>
<component componentID="16" access="read-write">
<name>EResultAdmin</name>
<synopsis>
Turn Extended results off or on.
default to off
</synopsis>
<typeRef>ExtendedResultType</typeRef>
<defaultValue>1</defaultValue>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportableVersions</name>
<synopsis>
the table of ForCES versions that FE supports
</synopsis>
<array type="variable-size">
<typeRef>uchar</typeRef>
</array>
</capability>
<capability componentID="31">
<name>HACapabilities</name>
<synopsis>
the table of HA capabilities the FE supports
</synopsis>
<array type="variable-size">
<typeRef>FEHACapab</typeRef>
</array>
</capability>
<capability componentID="32">
<name>EResultCapab</name>
<synopsis>
the table of supported result capabilities
</synopsis>
<array type="variable-size">
<typeRef>ExtendedResultType</typeRef>
</array>
</capability> </capability>
</capabilities> <capability componentID="31">
<events baseID="61"> <name>HACapabilities</name>
<event eventID="1"> <synopsis>
<name>PrimaryCEDown</name> The table of HA capabilities the FE supports
<synopsis> </synopsis>
The primary CE has changed <array type="variable-size">
</synopsis> <typeRef>FEHACapab</typeRef>
<eventTarget> </array>
<eventField>LastCEID</eventField> </capability>
</eventTarget> <capability componentID="32">
<eventChanged/> <name>EResultCapab</name>
<eventReports> <synopsis>
<eventReport> The table of supported result capabilities
<eventField>LastCEID</eventField> </synopsis>
</eventReport> <array type="variable-size">
</eventReports> <typeRef>ExtendedResultType</typeRef>
</event> </array>
<event eventID="2"> </capability>
<name>PrimaryCEChanged</name> </capabilities>
<synopsis>A New primary CE has been selected <events baseID="61">
</synopsis> <event eventID="1">
<eventTarget> <name>PrimaryCEDown</name>
<eventField>CEID</eventField> <synopsis>
</eventTarget> The primary CE has changed.
<eventChanged/> </synopsis>
<eventReports> <eventTarget>
<eventReport> <eventField>LastCEID</eventField>
<eventField>CEID</eventField> </eventTarget>
</eventReport> <eventChanged/>
</eventReports> <eventReports>
</event> <eventReport>
</events> <eventField>LastCEID</eventField>
</LFBClassDef> </eventReport>
</LFBClassDefs> </eventReports>
</LFBLibrary> </event>
<event eventID="2">
<name>PrimaryCEChanged</name>
<synopsis>A new primary CE has been selected.
</synopsis>
<eventTarget>
<eventField>CEID</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>CEID</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Acknowledgments
The author would like to thank Evangelos Haleplidis and Joel Halpern
for discussions that made this document better. Adrian Farrel did an
excellent AD review of the document, which improved the quality of
this document. Tobias Gondrom did the Security Directorate review.
Brian Carpenter did the Gen-ART review. Nevil Brownlee performed the
Operations Directorate review. S. Moonesamy (SM) worked hard to
review our publication process. Pearl Liang caught issues in the
IANA text.
The author would like to thank the following IESG members who
reviewed and improved this document: Alia Atlas, Barry Leiba, Brian
Haberman, Kathleen Moriarty, Richard Barnes, and Spencer Dawkins.
Author's Address Author's Address
Jamal Hadi Salim Jamal Hadi Salim
Mojatatu Networks Mojatatu Networks
Suite 400, 303 Moodie Dr. Suite 400, 303 Moodie Dr.
Ottawa, Ontario K2H 9R4 Ottawa, Ontario K2H 9R4
Canada Canada
Email: hadi@mojatatu.com EMail: hadi@mojatatu.com
 End of changes. 115 change blocks. 
764 lines changed or deleted 781 lines changed or added

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