draft-ietf-forces-protoextension-00.txt   draft-ietf-forces-protoextension-01.txt 
Internet Engineering Task Force J. Hadi Salim Internet Engineering Task Force J. Hadi Salim
Internet-Draft Mojatatu Networks Internet-Draft Mojatatu Networks
Intended status: Informational September 16, 2013 Intended status: Informational March 17, 2014
Expires: March 20, 2014 Expires: September 18, 2014
ForCES Protocol Extensions ForCES Protocol Extensions
draft-ietf-forces-protoextension-00 draft-ietf-forces-protoextension-01
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 document describes a few extensions to the ForCES Protocol This document describes extensions to the ForCES Protocol
Specification [RFC5810] semantics to achieve that end goal. Specification[RFC 5810] semantics to achieve that end goal.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 20, 2014. This Internet-Draft will expire on September 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Error codes . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Update Proposal . . . . . . . . . . . . . . . . . . 5 4. Protocol Update Proposal . . . . . . . . . . . . . . . . . . . 6
4.1. Extending Result-TLV . . . . . . . . . . . . . . . . . . 5 4.1. Table Ranges . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Table Ranges . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. New Codes . . . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Vendor Codes . . . . . . . . . . . . . . . . . . . . . 8
4.3.2. Extending Result TLV . . . . . . . . . . . . . . . . 8 4.2.3. Extended Result TLV . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.3. Large Object Dumping . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 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.2. Definitions 1.2. Definitions
skipping to change at page 4, line 4 skipping to change at page 4, line 31
protocol state transfer scheme, and the ForCES protocol protocol state transfer scheme, and the ForCES protocol
architecture itself as defined in the ForCES Protocol architecture itself as defined in the ForCES Protocol
Specification [RFC5810]. Specification [RFC5810].
ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in
ForCES protocol architecture that uses the capabilities of ForCES protocol architecture that uses the capabilities of
existing transport protocols to specifically address protocol existing transport protocols to specifically address protocol
message transportation issues, such as how the protocol messages message transportation issues, such as how the protocol messages
are mapped to different transport media (like TCP, IP, ATM, are mapped to different transport media (like TCP, IP, ATM,
Ethernet, etc.), and how to achieve and implement reliability, Ethernet, etc.), and how to achieve and implement reliability,
ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that ordering, etc. the ForCES SCTP TML [RFC5811] describes a TML that
is mandated for ForCES. is mandated for ForCES.
2. Introduction 2. 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
which are backward compatible. which are backward compatible. The document also clarifies on top of
[RFC5810] how dumping of large components is achieved.
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. application to request an arbitrary range of table rows.
2. Improved Error codes returned to the controller (or control 2. Improved Error codes returned to the controller (or control
application) to improve granularity of existing defined error application) to improve granularity of existing defined error
codes. codes.
3. FE response to a GET request (example to a large table) may not
fit in one PL message, for example due to limited TLV space.
3. Problem Overview 3. Problem Overview
In this section we present sample use cases to illustrate the In this section we present sample use cases to illustrate the
challenge being addressed. challenge being addressed.
3.1. Table Ranges 3.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.
ForCES GET requests sent from a controller (or control app) are ForCES GET and DEL requests sent from a controller (or control app)
prepended with a path to a component and sent to the FE. In the case are prepended with a path to a component and sent to the FE. In the
of indexed tables, the component path can either be to a table or a case of indexed tables, the component path can either be to a table
table row index. A control application attempting to retrieve the or a table row index. The approaches for retrieving or deleting a
first 2000 table rows appearing between row indices 23 and 10023 can sizeable number of table rows is at the programmatically level (from
an application point of view) unfriendly, tedious, and abusive of
both compute and bandwidth resources.
As an example, a control application attempting to retrieve the first
2000 table rows appearing between row indices 23 and 10023 can
achieve its goal in one of: achieve its goal in one of:
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 with monotonically incrementing o Send upto 10000 ForCES PL requests with monotonically incrementing
indices and stop when the needed 2000 entries are retrieved. indices and stop when the needed 2000 entries are retrieved.
o Use ForCES batching to send fewer large messages (several path o If the application had knowledge of which table rows existed (not
requests at a time with incrementing indices until you hit the unreasonable given the controller is supposed to be aware of state
require number of entries). within an NE), then the application could take advantage of ForCES
batching to send fewer large messages (each with different path
entries for a total of two thousand).
All of these approaches are programmatically (from an application As argued, while the above options exist - all are tedious.
point of view) unfriendly, tedious, and are seen as abuse of both
compute and bandwidth resources.
3.2. Error codes 3.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.
4. Protocol Update Proposal 4. Protocol Update Proposal
This section describes proposals to update the protocol for issues This section describes proposals to update the protocol for issues
discussed in Section 3 discussed in Section 3
4.1. Extending Result-TLV 4.1. Table Ranges
We extend the RESULT-TLV (0x114) to additionally carry an optional
description of the result. This is illustrated in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = RESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value | Cause code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Content |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Extended Result TLV
o As before, the Result TLV is expected to be 32 bit aligned.
o The Result Value is derived from the same current namespace as
specified in RFC 5810, section 7.1.7 with some new values added in
Section 4.3.
o The cause code is an enumeration which describes additional
content. This field was originally part of a reserved field. By
definition, the user was not supposed to interpret the reserved
field and the sender was expected to set it to 0. By default,
therefore, we assume 0 to imply the status quo i.e ignore cause
content if present. For this reason, we expect this new extension
to be both backward compatible and forward compatible because old
implementations ignore the reserved fields and always set them to
zero and new implementations will set and intepret the cause code.
4.2. Table Ranges
We propose to add a Table-range TLV (type ID 0x117) that will be We propose to add a Table-range 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.
OPER = GET +---------------------+---------------------+
PATH-DATA: | Type (0x117) | Length |
flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6} +---------------------+---------------------+
TABLERANGE-TLV = {11,23} | Start Index |
+-------------------------------------------+
| End Index |
+-------------------------------------------+
Figure 1: ForCES table range request Layout
Figure 1 shows how this new TLV is constructed.
OPER = GET
PATH-DATA:
flags = F_SELTABRANGE, IDCount = 2, IDs = {1,6}
TABLERANGE-TLV content = {11,23}
Figure 2: ForCES table range request Figure 2: ForCES table range request
Figure 2 illustrates a GET request for a a table range for rows 11 to Figure 2 illustrates a GET request for a range of rows 11 to 23 of a
23 of a table with component path of 1/6. table with component path of "1/6".
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) is set to indicate the presence of the Table- defined in RFC 5810) is set to indicate the presence of the
range TLV. The pathflag bit F_SELTABRANGE can only be used in a GET TABLERANGE-TLV. The pathflag bit F_SELTABRANGE can only be used in a
and is mutually exclusive with F_SELKEY. The FE MUST enforce those GET or DEL and is mutually exclusive with F_SELKEY. The FE MUST
constraints and reject a request with an error code of enforce those constraints and reject a request with an error code of
E_INVALID_FLAGS with an english description of what the problem is E_INVALID_TFLAGS with a description of what the problem is (refer to
(refer to Section 4.3). Section 4.2).
The Table-range 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 beggining 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 0xFFFFFFFFFFFFFFFF implies the
last entry. XXX: Do we need to define the "end wildcard"? 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 contain 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 A result TLV when: o An EXTENDEDRESULT-TLV (refer to Section 4.2.3) when:
* data is absent where the result code of E_NOT_SUPPORTED * Response is to a range delete request. The Result will either
(typically returned in current implementations when accessing be:
an empty table entry) with an english message describing the
nature of the error (refer to Section 4.3). + A success if any of the requested-for rows is deleted
+ A proper error code if none of the requested for rows can be
deleted
* data is absent where the result code of E_EMPTY with an
optional content string describing the nature of the error
(refer to Section 4.2).
* When both a path key and path table range are reflected on the * When both a path key and path table range are reflected on the
the pathflags, an error code of E_INVALID_FLAGS with an english the pathflags, an error code of E_INVALID_TFLAGS with an
message describing the nature of the erro (refer to optional content string describing the nature of the error
Section 4.3). (refer to Section 4.2).
* other standard ForCES errors (such as ACL constraints trying to * other standard ForCES errors (such as ACL constraints trying to
retrieve contents of an unreadable table), accessing unknown retrieve contents of an unreadable table), accessing unknown
components etc. components etc.
4.3. Error Codes 4.2. Error Codes
We propose two things: We propose several things:
o A new set of error codes. 1. A new set of error codes.
o A cause string to be carried in the new proposed RESULT-TLV. 2. Allocating currently reserved codes for vendor use.
4.3.1. New Codes 3. A new TLV, EXTENDEDRESULT-TLV (0x118) that will carry a code
(which will be a superset of what is currently specified in RFC
5812) but also an optional cause content. This is illustrated in
Figure 3.
The following error codes are added. 4.2.1. New Codes
+-----------------------+--------+----------------------------------+ EXTENDEDRESULT-TLV Result Value is 32 bits and is a superset of RFC
| Result Value | Value | Definition | 5810 Result TLV Result Value. The new version code space is 32 bits
+-----------------------+--------+----------------------------------+ as opposed to the RFC 5810 code size of 8 bits.
| E_TIMED_OUT | 0x18 | A time out occured while |
| | | processing the message |
| E_CONGEST_NT | 0x19 | The message was successfully |
| | | processed but there is |
| | | congestion detected. |
| E_EMPTY | 0x1A | A requested for table in a GET |
| | | operation is empty |
| E_INVALID_PATH_FLGS | 0x1B | The submitted path flags in a |
| | | request are invalid |
| E_UNKNOWN | 0x1C | A generic error catch all error |
| | | code. To be useful, presented |
| | | only in association with |
| | | extended Result TLV from below |
| | | and carries a string to further |
| | | extrapolate what the error |
| | | implies. |
+-----------------------+--------+----------------------------------+
Table 1 +------------+-------------------------+----------------------------+
| Code | Mnemonic | Details |
+------------+-------------------------+----------------------------+
| 0x100 | E_EMPTY | Table is empty |
| 0x101 | E_INVALID_TFLAGS | Invalid table flags |
| 0x102 | E_INVALID_OP | Requested operation is |
| | | invalid |
| 0x103 | E_CONGEST_NT | Node Congestion |
| | | notification |
| 0x104 | E_COMPONENT_NOT_A_TABLE | Component not a table |
| 0x105 | E_PERM | Operation not permitted |
| 0x107 | E_BUSY | System is Busy |
| 0x108 | E_TIMED_OUT | A time out occured while |
| | | processing the message |
| 0x106 | E_UNKNOWN | A generic catch all error |
| | | code. Carries a string to |
| | | further extrapolate what |
| | | the error implies. |
+------------+-------------------------+----------------------------+
XXX: More error codes to be added in later doc revisions. Table 1: New codes
4.3.2. Extending Result TLV 4.2.2. Vendor Codes
We introduce a cause content of a string to further describe the Codes 0x18-0xFE are reserved for use as vendor codes. Since these
error code. The result TLV is shown in Figure 3. The content code are freely available it is expected that the FE and CE side will both
will be 1 indicating the cause content is an UTF-8 string[N] cause understand/interpret the semantics of any used codes.
description.
4.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 = RESULT-TLV | Length | | Type = EXTENDEDRESULT-TLV | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Value |Cause code = 1 | Reserved | | Result Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause String[32] | | Optional Cause content |
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Extending The Result TLV Figure 3: EXTENDEDRESULT-TLV
It is recommended that the maximum size of the cause string should o Like all other ForCES TLVs, the EXTENDEDRESULT-TLV is expected to
not exceed 32 bytes. We do not propose the cause string be be 32 bit aligned.
standardized.
5. IANA Considerations o The Result Value derives and extends from the same current
namespace as 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).
o The optional result content is defined to further disambiguate the
result value. It is expected Utf-8 values to be used. However,
vendor specific error codes may choose to specify different
contents. Additionally, future codes may specify cause contents
to be of types other than string..
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
standardized.
XXX: Backward compatibility may require that we add a FEPO capability
to advertise ability to do extended results so that the CE is able to
interpret the results and a FEPO compatibility flag to define what
TLV setting would be used. Alternatively, the backward compatibility
can be made a configuration option (which helps reduce clutter on
FEPO LFB given that it is expected that in the future it makes sense
for implementations to support only EXTENDEDRESULT-TLVs).
4.3. Large Object Dumping
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.
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
that the FE delivers the response over multiple messages, all using
the same correlator X.
RFC 5810 does not describe how a GET response is to indicate "I have
more messages coming for this correlator".
Implementation experience 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.
XXX: Add in the next update diagram and details of how this takes
place.
5. Acknowledgements
TBA
6. IANA Considerations
This document registers two new top Level TLVs and two new path This document registers two new top Level TLVs and two new path
flags. flags.
The following new TLVs are defined: The following new TLVs are defined:
o Table-range TLV (type ID 0x117) o TABLERANGE-TLV (type ID 0x117)
o EXTENDED RESULT-TLV Cause codes. o EXTENDEDRESULT-TLV (type ID 0x118)
The following new path flags are defined: The following new path flags are defined:
o F_SELTABRANGE (value 0x2 i.e bit 1) o F_SELTABRANGE (value 0x2 i.e bit 1)
6. Security Considerations The Defined Result Values are changed:
o codes 0x18-0xFE are reserved for vendor use.
o codes 0x100-102 are defined by this document.
7. Security Considerations
TBD TBD
7. References 8. References
7.1. Normative References 8.1. Normative 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.
[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
Element Separation (ForCES) Forwarding Element Model", RFC Element Separation (ForCES) Forwarding Element Model",
5812, March 2010. RFC 5812, March 2010.
7.2. Informative References 8.2. Informative 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.
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
 End of changes. 46 change blocks. 
147 lines changed or deleted 198 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/