draft-ietf-forces-protoextension-04.txt   draft-ietf-forces-protoextension-05.txt 
Internet Engineering Task Force J. Hadi Salim Internet Engineering Task Force J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Updates: 7121,5810 (if approved) July 30, 2014 Updates: 7121,5810 (if approved) August 18, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: January 31, 2015 Expires: February 19, 2015
ForCES Protocol Extensions ForCES Protocol Extensions
draft-ietf-forces-protoextension-04 draft-ietf-forces-protoextension-05
Abstract Abstract
Experience in implementing and deploying ForCES architecture has Experience in implementing and deploying ForCES architecture has
demonstrated need for a few small extensions both to ease demonstrated 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 documents updates both RFC 5810 and RFC 7121 semantics to This documents updates both RFC 5810 and RFC 7121 semantics to
achieve that end goal. achieve that end goal.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 31, 2015. This Internet-Draft will expire on February 19, 2015.
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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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. Definitions . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Update Proposal . . . . . . . . . . . . . . . . . . . 5 3. Protocol Update . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 9 3.3. Large Table Dumping . . . . . . . . . . . . . . . . . . . 10
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 12 Appendix A. Appendix A - New FEPO version . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
Experience in implementing and deploying ForCES architecture has Experience in implementing and deploying ForCES architecture has
demonstrated need for a few small extensions both to ease demonstrated 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 ForCES Protocol
Specification [RFC5810] semantics to achieve that end goal. Specification [RFC5810] semantics to achieve that end goal.
This document describes and justifies the need for 2 small extensions This document describes and justifies the need for 2 small extensions
skipping to change at page 3, line 44 skipping to change at page 3, line 44
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. Definitions
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 sake
of contexual clarity. of contextual clarity.
Control Engine (CE)
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
skipping to change at page 4, line 14 skipping to change at page 4, line 18
LFB Instance LFB Instance
LFB Model LFB Model
LFB Metadata LFB Metadata
ForCES Component ForCES Component
LFB Component LFB Component
ForCES Protocol the ForCES Framework [RFC3746]. the ForCES SCTP
TML [RFC5811] describes a TML
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 which 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 sizeable number of table rows is at the retrieving or deleting a sizable number of table rows to be both
programmatically level (from an application point of view) programmatically tedious and inefficient on utilization of both
unfriendly, tedious, and abusive of both compute and bandwidth compute and wire resources.
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 app) are prepended with a path to a component and sent to the
FE. In the case of indexed tables, the component path can either FE. In the case of indexed tables, the component path can either
point to a table or a table row index. point to 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:
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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 be then 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 Proposal 3. Protocol Update
This section describes proposals to update the protocol for issues This section describes normative update to the ForCES protocol for
discussed in Section 2 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 0x117) 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.
+---------------------+---------------------+ 0 1 2 3
| Type (0x117) | Length | 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
+---------------------+---------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Index | | Type (0x117) | Length |
+-------------------------------------------+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Index | | Start 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 1 shows how this new TLV is constructed.
OPER = GET OPER = GET
PATH-DATA: PATH-DATA:
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}
skipping to change at page 6, line 25 skipping to change at page 6, line 25
Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as Path flag of F_SELTABRANGE (0x2 i.e bit 1, where bit 0 is F_SELKEY as
defined in RFC 5810) MUST be set to indicate the presence of the defined in RFC 5810) MUST be set to indicate the presence of the
TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a
GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST
enforce the path flag constraints and ensure that the selected path enforce the path flag constraints and ensure that the selected path
belongs to a defined indexed table component. Any violation of these belongs to a defined indexed table component. Any violation of these
constraints MUST be rejected with an error code of E_INVALID_TFLAGS constraints MUST be rejected with an error code of E_INVALID_TFLAGS
with a description of what the problem is when using extended error with a description of what the problem is when using extended error
reporting (refer to Section 3.2). reporting (refer to Section 3.2).
It should be noted thata there are combination of path selection
mechanisms that should not appear together for the sake of simplicity
of operations. These include: TABLERANGE-TLV and KEYINFO-TLV as well
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 beggining 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 0xFFFFFFFFFFFFFFFF implies the o A 32 bit end index. A value of 0xFFFFFFFF implies the last entry.
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 contain 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
sparsedata TLV. The sparse data TLV content will have the "I" (in sparsedata TLV. The sparse data TLV content will have the "I" (in
ILV) for each table row indicating the table indices. 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 * Response is to a range delete request. The Result will either
be: be:
+ A success if any of the requested-for rows is deleted + A success if any of the requested-for rows is deleted
skipping to change at page 7, line 36 skipping to change at page 7, line 38
3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code 3. A new TLV, EXTENDEDRESULT-TLV (0x118) 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]) but also 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 EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC
5810 Result TLV Result Value. The new version code space is 32 bits 5810 Result TLV Result Value. The new version code space is 32 bits
as opposed to the RFC 5810 code size of 8 bits. The first 8 bit as opposed to the RFC 5810 code size of 8 bits. The first 8 bit
values are common to both old 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 time out occured 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 |
skipping to change at page 8, line 41 skipping to change at page 9, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 RESULT-TLV Result Value as
specified in RFC 5810, section 7.1.7. The main difference is that specified in RFC 5810, section 7.1.7. The main difference is that
we now have 32 bit result value (as opposed to the old 8 bit). we now have a 32 bit result value (as opposed to old 8 bit).
o The optional result content is defined to further disambiguate the o The optional result content is defined to further disambiguate the
result value. It is expected Utf-8 string values to be used. result value. It is expected UTF-8 string values to be used.
However, vendor specific error codes may choose to specify However, vendor specific error codes may choose to specify
different contents. Additionally, future codes may specify cause different contents. Additionally, future codes may specify cause
contents to be of types other than string.. contents 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. We do not propose the cause string be not exceed 32 bytes. We do not propose the cause string be
standardized. standardized.
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 To support backward compatibility, we update and the FEPO LFB (in
Appendix A version to 1.2. We also add a new component ID 16 (named Appendix A) version to 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 supporting
both modes will assume the lowest common denominator i.e EResultAdmin both modes will assume the lowest common denominator i.e EResultAdmin
will be EResultNotSupported; and will issue responses using RESULT- will be EResultNotSupported; and will issue responses using RESULT-
TLVs. It should be noted an FE advertising FEPO version 1.2 MUST TLVs. It should be noted an FE advertising FEPO version 1.2 MUST
support EXTENDEDRESULT-TLVs at minimum. support EXTENDEDRESULT-TLVs at minimum.
On an FE which supports both RESULT-TLVs and EXTENDEDRESULT-TLVs, a On an FE which 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
value to 2 in which case the FE MUST switch over to sending only EResultAdmin value to 2 in which case the FE MUST switch over to
EXTENDEDRESULT-TLVs. Likewise a master CE can turn off extended sending only EXTENDEDRESULT-TLVs. Likewise a master CE can turn off
result responses by writting a 1 to the EResultAdmin. An FE that extended result responses by writing a 1 to the EResultAdmin. An FE
does not support one mode or other MUST reject setting of that does not support one mode or other MUST reject setting of
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. error code of E_NOT_SUPPORTED. It is expected that all CEs
participating in a high availability(HA) mode be capable of
supporting FEPO version 1.2 whenever EResultAdmin is set to strict
support of EXTENDEDRESULT-TLVs. The consensus between CEs in an HA
setup to set strict support of EXTENDEDRESULT-TLVs is out of scope
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, lets 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.
skipping to change at page 10, line 10 skipping to change at page 11, line 10
Implementation experience of dumping large tables indicates we can Implementation experience of dumping large tables indicates we can
use the transaction flags to indicate that a GET response is the 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 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. mirror the effect of an atomic transaction sent by a CE to an FE.
CE PL FE PL CE PL FE PL
| | | |
| (0) Query, Path-to-a-large-table, OP=GET | | (0) Query, Path-to-a-large-table, OP=GET |
|----------------------------------------------------->| |----------------------------------------------------->|
| correlattor = X | | correlator = X |
| | | |
| (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA | | (1) Query-Response, SOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| correlattor = X | | correlator = X |
| DATA TLV (SPARSE/FULL) | | DATA TLV (SPARSE/FULL) |
| | | |
| (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | | (2) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| correlattor = X | | correlator = X |
| DATA TLV (SPARSE/FULL) | | DATA TLV (SPARSE/FULL) |
| | | |
| (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | | (3) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| correlattor = X | | correlator = X |
| DATA TLV (SPARSE/FULL) | | DATA TLV (SPARSE/FULL) |
. . . .
. . . .
. . . .
. . . .
| | | |
| (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA | | (N) Query-Response, MOT,AT, OP=GET-RESPONSE, DATA |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| correlattor = X | | correlator = X |
| DATA TLV (SPARSE/FULL) | | DATA TLV (SPARSE/FULL) |
| | | |
| (N) Query-Response, EOT,AT, OP=GET-RESPONSE | | (N) Query-Response, EOT,AT, OP=GET-RESPONSE |
|<-----------------------------------------------------| |<-----------------------------------------------------|
| correlattor = X | | correlator = X |
| RESULT TLV (SUCCESS) | | RESULT TLV (SUCCESS) |
| | | |
Figure 4: EXTENDEDRESULT-TLV Figure 4: EXTENDEDRESULT-TLV
The last message which carries the EOT flag to go the CE MUST NOT The last message which carries the EOT flag to go the CE MUST NOT
carry any data. This allows us to mirror ForCES 2PC messaging carry any data. This allows us to mirror ForCES 2PC messaging
[RFC5810] where the last message is an empty commit message. GET [RFC5810] where the last message is an empty commit message. GET
response will carry a result code TLV in such a case. response will carry a result code TLV in such a case.
4. Acknowledgements 4. Acknowledgements
The author would like to thank Evangelos Haleplidis and Joel Halpern The author would like to thank Evangelos Haleplidis and Joel Halpern
for discussions that made this document better. Adrian Farrel did an for discussions that made this document better. Adrian Farrel did an
excellent AD review of the document which improved the quality of excellent AD review of the document which improved the quality of
this document. 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. Perl Liang caught issues in the IANA
specification.
5. IANA Considerations 5. IANA Considerations
This document registers two new top Level TLVs and two new path flags This document registers two new top Level TLVs and two new path flags
and updates an IANA registered FE Protocol object Logical Functional and updates an IANA registered FE Protocol object Logical Functional
Block (LFB). Block (LFB).
The Appendix A defines an update to the FE Protocol Object LFB to The Appendix A defines an update to the FE Protocol Object LFB to
version 1.2. XXX: comment to IANA: The IANA registry version 1.2. The IANA registry
https://www.iana.org/assignments/forces/forces.xml sub-registy https://www.iana.org/assignments/forces sub-registy "Logical
"Logical Functional Block (LFB) Class Names and Class Identifiers" Functional Block (LFB) Class Names and Class Identifiers" will need
will need to be updated for FE Protocol Object LFB version from 1.1 to be append for FE Protocol Object LFB version 1.2 and this document
to 1.2 and this document reflected in the reference column. reflected in the reference column.
XXX: comments to IANA - updates required to the "TLV types" Updates are required to the "TLV types" subregistry for the TLVs
subregistry for the TLVs below. below.
The following new TLVs are defined: The following new TLVs are defined:
o TABLERANGE-TLV (type ID 0x117) o TABLERANGE-TLV (type ID 0x117)
o EXTENDEDRESULT-TLV (type ID 0x118) o EXTENDEDRESULT-TLV (type ID 0x118)
XXX: Comment to IANA, section below affects subregistry "RESULT-TLV subregistry "RESULT-TLV Result Values" is affected by the entries
Result Values" below.
The Defined RESULT-TLV Result Values are changed: The Defined RESULT-TLV Result Values are changed:
o codes 0x21-0xFE are unassigned. o codes 0x21-0xFE are 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.
XXX: Note to IANA - codes 0x18-0x20 need approval of the designated A new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be
expert (In this case Joel Halpern since the author is the other
expert).
A a new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be
created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result
Values sub-registry and must not be allocated. The codes 0x100-0x200 Values sub-registry. Any new allocations of this code range (in the
are reserved for private use as described earlier and the codes range 0x21-0xfe) must happen only within the new sub-registry and not
0x200-0xffffffff are reserved for future use; these codes will be in RESULT-TLV Result Values sub-registry. The codes 0x100-0x200 are
allocated on First Come First Served basis and require specification reserved for private use as described earlier and the code ranges
as well approval of an expert review. 0x21-0xfe and 0x201-0xffffffff should be marked as Unassigned with
the IANA allocation policy of Specification Required [RFC5226].
6. Security Considerations 6. Security Considerations
The security considerations that have been described in the ForCES The security considerations that have been described in the ForCES
protocol [RFC5810] apply to this document as well. protocol [RFC5810] apply to this document as well.
7. References 7. References
7.1. Normative References 7.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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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.
[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.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
skipping to change at page 12, line 44 skipping to change at page 14, line 7
February 2014. February 2014.
7.2. Informative References 7.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.
Appendix A. Appendix A - New FEPO version Appendix A. Appendix A - New FEPO version
This version of FEPO updates the earlier one given in RFC 7121. The
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>
skipping to change at page 14, line 19 skipping to change at page 15, line 28
<name>FERestartPolicyValues</name> <name>FERestartPolicyValues</name>
<synopsis> <synopsis>
The possible values of FE restart policy The possible values of FE restart policy
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>FERestartPolicy0</name> <name>FERestartPolicy0</name>
<synopsis> <synopsis>
The FE restart restats its state from scratch The FE restarts its state from scratch
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>HAModeValues</name> <name>HAModeValues</name>
<synopsis> <synopsis>
The possible values of HA modes The possible values of HA modes
</synopsis> </synopsis>
 End of changes. 40 change blocks. 
74 lines changed or deleted 93 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/