One document matched: draft-ietf-teas-lsp-attribute-ro-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc category="std" docName="draft-ietf-teas-lsp-attribute-ro-04"
ipr="trust200902" >
<front>
<title abbrev="General ERO LSP parameters">LSP Attribute in ERO</title>
<author fullname="Cyril Margaria" initials="C." role="editor" surname="Margaria">
<organization>Juniper</organization>
<address>
<postal>
<street>200 Somerset Corporate Boulevard, , Suite 4001</street>
<city>Bridgewater</city>
<region>NJ</region>
<code>08807</code>
<country>USA</country>
</postal>
<email>cmargaria@juniper.net</email>
</address>
</author>
<author fullname="Giovanni Martinelli" initials="G.M."
surname="Martinelli">
<organization>Cisco</organization>
<address>
<postal>
<street> via Philips 12</street>
<code>20900</code>
<city>Monza</city>
<country>IT</country>
</postal>
<phone>+39 039 209 2044</phone>
<email>giomarti@cisco.com</email>
</address>
</author>
<author fullname="Steve Balls" initials="S." surname="Balls">
<organization>Metaswitch</organization>
<address>
<postal>
<street>100 Church Street</street>
<code>EN2 6BQ</code>
<city>Enfield</city>
<country>GB</country>
</postal>
<phone>+44 208 366 1177</phone>
<email>steve.balls@metaswitch.com</email>
</address>
</author>
<author fullname="Ben Wright" initials="B." surname="Wright">
<organization>Metaswitch</organization>
<address>
<postal>
<street>100 Church Street</street>
<code>EN2 6BQ</code>
<city>Enfield</city>
<country>GB</country>
</postal>
<phone>+44 208 366 1177</phone>
<email>Ben.Wright@metaswitch.com</email>
</address>
</author>
<!-- Meta-data Declarations -->
<date day="04" month="March" year="2015" />
<area>Routing</area>
<workgroup>TEAS</workgroup>
<keyword>RSVP-TE</keyword>
<keyword>GMPLS</keyword>
<abstract>
<t>
RFC5420 extends RSVP-TE to specify or record generic attributes which apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) objects to allow it to specify or record generic attributes which apply to a given hop. </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) can be
route-constrained by making use of the Explicit Route object (ERO) and related sub-objects
as defined in
<xref target="RFC3209" />, <xref target="RFC3473" />, <xref target="RFC3477" />,
<xref target="RFC4873" />, <xref target="RFC4874" />, <xref target="RFC5520" /> and
<xref target="RFC5553" />.
Several documents have identified the need for attributes that can be targeted
at specific hops in the path of an LSP, including <xref target="RFC6163" />, <xref target="I-D.ietf-ccamp-wson-signaling" />,
<xref target="I-D.ietf-teas-rsvp-te-li-lb" /> or <xref target="I-D.ali-ccamp-rc-objective-function-metric-bound" />. This document provides a
generic mechanism for use by these other documents.
</t>
<t>
RSVP already supports generic extension of LSP Attributes in <xref target="RFC5420" />. In order to support current and future ERO constraint extensions this document provides a mechanism to define per-Hop attributes.
</t>
<t>
The document describes a generic mechanism for carrying information
related to specific nodes when signaling an LSP. This document does not
restrict what that information can be used for. The defined approach
builds on LSP Attributes defined in [RFC5420], and enables attributes to be
expressed in ERO and Secondary Explicit Route object (SERO) objects. A
new ERO sub-object is defined, containing a list of generic per-Hop
attributes.
</t>
<section title ="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119" >RFC 2119</xref>.
</t>
</section>
</section>
<section title="ERO Hop Attributes Subobject" anchor="ERO_Hop_atttribute">
<t>
The ERO Hop Attributes subobject MAY be carried in the ERO or SERO object if they are present.
The subobject uses the standard format of an ERO subobject.
</t>
<section title="Encoding">
<t>
The length is variable and content is a list of HOP Attributes TLVs defined in <xref target='hop_attribute_tlv' />.
The size of the ERO sub-object limits the size of the attribute TLV to 250 bytes.
The typical size of currently defined and forthcoming LSP_ATTRIBUTE TLVs applicable to a specific hop (WSON_SIGNALING, Objective Function (OF) and Metric) is not foreseen to exceed this limit.
</t>
<t>
The ERO Hop Attributes subobject is defined as follows:
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
The L, Type and Length parameters are as defined in <xref target="RFC3209"/> Section 4.3.3.
The L bit MUST be set to 0.
The Type for the ERO Hop Attributes subobject is TBA by IANA.
The attributes TLV are encoded as defined in <xref target='hop_attribute_tlv' />.
</t>
<t>
<list style='hanging' >
<t hangText='Reserved'> Reserved, MUST be set to 0 when the subobject is inserted in the ERO, MUST NOT be changed when a node processes the ERO and MUST be ignored on the node addressed by the preceding ERO subobjects.</t>
<t hangText='R'> This bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic defined in <xref target='RFC5420' />. When set it indicates required hop attributes to be processed by the node. When cleared, it indicates that the hop attributes are not required as described in <xref target="ERO_HOP_ATTRIBUTE_procedure" />.
</t>
<t hangText='Attributes TLVs'>The TLVs as defined in <xref target='hop_attribute_tlv' />.</t>
</list>
</t>
</section> <!-- ERO LSP_ATTRIBUTE subobject-->
<section title="HOP Attributes TLVs" anchor='hop_attribute_tlv'>
<t>
ERO Attributes carried by the new objects defined in this document are
encoded within TLVs. One or more TLVs MAY be present in each object.
There are no ordering rules for TLVs, and interpretation SHOULD NOT be
placed on the order in which TLVs are received.
The TLV format is defined in <xref target="RFC5420" /> Section 3.
</t>
<t>
The Attribute Flags TLV defined in <xref target="RFC5420" /> MAY be carried in an
ERO Hop Attributes Subobject. Flags set in the an Attribute Flags
TLV <xref target="RFC5420" /> carried in an ERO Hop Attributes Subobject SHALL be
interpreted in the context of the received ERO. Only a subset of
defined flags are defined as valid for use in Attribute Flags TLV
carried in an ERO Hop Attributes Subobject. Invalid flags SHALL be
silently ignored. Unknown flags SHOULD trigger the generation of
a PathErr with Error Code "Unknown Attributes Bit" as defined in
<xref target="RFC5420" /> Section 5.2.
The set of valid flags are defined in <xref target="IANA_ATTR_FLAG" />.
</t>
<t>
The presence and ordering rule of the Attribute Flags TLV in an ERO Hop Attributes Subobject is defined by each Flag.
A document defining a Flag to be used in an Attribute Flags TLV carried in the ERO Hop Attributes Subobject has to describe:
<list style='symbols'>
<t>after which kinds of ERO subobject the Flag is valid</t>
<t>if ordering of the Flag and other ERO subobjects
associated with the same hop (e.g., Label subobjects) is significant,</t>
<t>if ordering is significant, how the Flag is interpreted in
association with the preceding subobjects,</t>
<t>any Flag modification rules that might apply.</t>
</list>
</t>
</section> <!-- end Hop attribute -->
<section title="Procedures" anchor="ERO_HOP_ATTRIBUTE_procedure">
<t>
As described in <xref target="RFC3209" /> the ERO is managed as a list of subobjects
each identifying a specific entity, an abstract node or a link that defines
a waypoint in the network path. Identifying subobjects of various types are
defined in <xref target="RFC3209" />, <xref target="RFC3477" />,
<xref target="RFC4873" />, <xref target="RFC4874" />, <xref target="RFC5520" /> and
<xref target="RFC5553" />.
</t>
<t>
<xref target="RFC3473" /> modified the ERO list by allowing one or two Label subobjects
to be interposed in the list after a subobject identifying a link. One or more ERO Hop Attributes
subobjects applicable to a particular hop MAY be inserted directly after
any of the existing identifying subobjects defined in<xref target="RFC3209" />, <xref target="RFC3477" />,
<xref target="RFC4873" />, <xref target="RFC4874" />, <xref target="RFC5520" /> and
<xref target="RFC5553" />. If any Label subobjects
are present for a hop, the ERO Hop Attributes subobject(s) MAY also be
inserted after the Label subobjects.
</t>
<t>
The attributes specified in an ERO Hop Attributes subobject apply to the immediately preceding
subobject(s) in the ERO subobject list.
</t>
<t>
A document defining a specific Hop Attribute TLV has to describe:
<list style='symbols'>
<t>after which kinds of ERO subobject they are valid ,</t>
<t>if ordering of the Hop Attributes subobject and other ERO subobjects
associated with the same hop (e.g., Label subobjects) is significant,</t>
<t>if ordering is significant, how the attribute is interpreted in
association with the preceding ERO subobjects, and</t>
<t> any TLV modification rules that might apply.</t>
</list>
For instance, subobject presence rules can be defined by describing rules similar to <xref target="RFC4990" /> Section 6.1.
</t>
<t>
If a node is processing an ERO Hop Attributes subobject and does not support
handling of the subobject it will behave as described in <xref target="RFC3209" /> when
an unrecognized ERO subobject is encountered. This
node will return a PathErr with error code "Routing Error" and error
value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
included, truncated (on the left) to the offending unrecognized subobject.</t>
<t>
When the R bit is set a node MUST examine the attribute TLV present in the subobject following the rules described in <xref target="RFC5420" /> Section 5.2.
When the R bit is not set a node MUST examine the attribute TLV present in the subobject following the rules described in <xref target="RFC5420" /> Section 4.2.
</t>
<t>
A node processing an ERO Hop Attributes subobject with a HOP Attributes TLV longer than the ERO subobject SHOULD return a PathErr with error code
"Routing Error" and error value "Bad EXPLICIT_ROUTE object" with the EXPLICIT_ROUTE object
included, truncated (on the left) to the offending malformed subobject.
A processing node MUST NOT originates a HOP Attributes TLV longer than the ERO HOP Attributes Subobject.
The processing of the Hop attribute TLVs SHOULD be described in the documents defining them.
</t>
</section> <!-- end procedures -->
</section> <!-- end LSP Attribute ERO subobject -->
<section title='RRO Hop Attributes Subobject' anchor="RRO_Hop_atttribute">
<t> In some cases it is important to determine if an OPTIONAL Hop attribute has been processed by a node.</t>
<section title='Encoding'>
<t>The RRO Hop Attributes subobject MAY be carried in the RECORD_ROUTE
object if it is present. The subobject uses the standard format of
an RRO subobject.
</t>
<t>
The RRO Hop Attributes subobject is defined as follows:
<figure>
<artwork><![CDATA[
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
The Type and Length parameters are as defined in <xref target="RFC3209"/> Section 4.4.1.
The Type for the RRO Hop Attributes subobject is TBA by IANA.
The attributes TLV are encoded as defined in <xref target='hop_attribute_tlv' />.
</t>
<t>
<list style='hanging' >
<t hangText='Reserved'> Reserved, MUST be set to 0 when the subobject is inserted in the RRO, MUST NOT be changed when a node process the RRO and MUST be ignored on the node addressed by the preceding RRO subobjects.</t>
<t hangText='Attributes TLVs'>The processed or additional HOP Attributes, using the format defined in <xref target='hop_attribute_tlv' />.</t>
</list>
</t>
</section>
<section title='Procedures'>
<section title='Subobject Presence Rule'>
<t> The RRO rules defined in <xref target="RFC3209" /> are not changed. The RRO Hop Attributes subobject MUST be pushed after the RRO Attributes subobject (if present) defined in <xref target="RFC5420" />. The RRO Hop Attributes subobject MAY be present between a pair of subobjects identifying Label Switching Router (LSR) or links. Unless local policy apply all such subobjects SHOULD be forwarded unmodified by transit LSRs.</t>
<t>
It is noted that a node (e.g., a domain edge node) MAY edit the
RRO to prune/modify the RRO, including the RRO Hop Attribute subobject before forwarding due to confidentiality policy or other reasons (for instance RRO size reduction).
</t>
</section>
<section title='Reporting Compliance with ERO Hop Attributes'>
<t>
To report that an ERO Hop attribute has been considered, or to report an additional attribute, an LSR MAY add a
RRO Hop Attributes subobject with the HOP Attribute TLV which describes the attribute to be reported.
The requirement to report compliance MUST be specified in the
document that defines the usage of a Hop attribute.
</t>
</section> <!-- End of reporting compliance -->
<section title='Compatibility with RRO Attributes subobject'>
<t>
The RRO Hop Attributes subobject extends the capability of the RRO Attributes subobject defined in <xref target="RFC5420" /> Section 7.2 by allowing the node to report the attribute value.
The mechanism defined in this document is compatible with the RRO Attributes subobject using the following procedures.
</t>
<t>
For LSP attributes signaled in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects, a node SHOULD use the RRO Attributes subobject to report processing of those attributes.
</t>
<t>
For LSP attributes signaled in the ERO Hop Attributes subobject and not in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES objects, if a node desires to report the attributes, it SHOULD use the RRO Hop Attributes subobject and SHOULD NOT use the RRO Attributes subobject. Ingress nodes not supporting the RRO Hop Attributes subobject will drop the information, as described in <xref target="RFC3209" /> Section 4.4.5.
</t>
<t> A node MAY use the RRO Hop Attribute to report an LSP Attribute signaled in LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES only if the following conditions are met:
<list>
<t>The Attribute and its corresponding flag is allowed on both the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES and LSP Hop Attributes subobject.</t>
<t>The document defining this Attribute specify this specific behavior.</t>
</list>
</t>
</section><!-- End of Compatibility with RRO Attributes subobject-->
</section> <!-- end procedures -->
</section> <!-- End of recording Hop attribute per LSP -->
<section title="IANA Considerations" anchor="IANA">
<section title="ERO Hop Attribute Subobject" anchor="IANA_ERO">
<t>
IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. We request IANA to
make an allocation in the Sub-object type 20 EXPLICIT_ROUTE -
Type 1 Explicit Route registry.
</t>
<t> This document introduces a new ERO sub-object:</t>
<texttable suppress-title='true' style='none'>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<c>Value</c> <c>Description</c> <c>Reference</c>
<c>------</c><c>-----------------</c><c>------------------------</c>
<c>TBA</c> <c>Hop Attributes</c><c>This document, <xref target="ERO_Hop_atttribute" /> </c>
</texttable>
</section>
<section title="RRO LSP Attribute Subobject" anchor="IANA_RRO">
<t>
IANA manages the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. We request IANA to
make an allocation in the Sub-object type 21 ROUTE_RECORD -
Type 1 Route Record registry.
We request the value to be the same as <xref target="IANA_ERO" />.
</t>
<t> This document introduces a new RRO sub-object:</t>
<texttable suppress-title='true' style='none'>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<c>Value </c><c>Description</c> <c>Reference</c>
<c>------</c><c>-----------------</c><c>------------------------</c>
<c>TBA</c> <c>Hop Attributes</c><c>This document, <xref target="RRO_Hop_atttribute" /> </c>
</texttable>
</section>
<section title="Existing Attribute Flags" anchor="IANA_ATTR_FLAG">
<t>
IANA manages the "Attribute Flags" registry as part of the
"RSVP-TE PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml. A new column in the registry is introduced
by this document. This column indicates if the flag is permitted to be used in an Attribute Flags TLV carried in the ERO Hop Attributes Subobject.
The column uses the heading "ERO" and the registry is to be updated as follows:
</t>
<texttable suppress-title='true' style='none'>
<ttcol align='left'></ttcol> <!-- Bit -->
<ttcol align='left'></ttcol> <!-- Name-->
<ttcol align='left'></ttcol> <!-- AttrFlag Path -->
<ttcol align='left'></ttcol> <!-- AttrFlag Resv -->
<ttcol align='left'></ttcol> <!-- RRO -->
<ttcol align='left'></ttcol> <!-- ERO -->
<ttcol align='left'></ttcol> <!-- Reference -->
<c>Bit</c><c>Name</c> <c>Attribute</c><c>Attribute</c><c>RRO</c><c>ERO</c><c>Reference</c>
<c> </c><c></c> <c>FlagsPath</c><c>FlagsResv</c><c></c> <c></c> <c></c>
<c>0</c><c>End-to-end re-routing</c> <c>Yes</c> <c>No</c> <c>No</c> <c>No</c> <c><xref target="RFC4920" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>1</c><c>Boundary re-routing</c> <c>Yes</c> <c>No</c> <c>No</c> <c>No</c> <c><xref target="RFC4920" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>2</c><c>Segment-based re-routing</c> <c>Yes</c> <c>No</c> <c>No</c> <c>No</c> <c><xref target="RFC4920" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>3</c><c>LSP Integrity Required</c> <c>Yes</c> <c>No</c> <c>No</c> <c>No</c> <c><xref target="RFC4875" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>4</c><c>Contiguous LSP</c> <c>Yes</c> <c>No</c> <c>Yes</c><c>No</c> <c><xref target="RFC5151" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>5</c><c>LSP stitching desired</c> <c>Yes</c> <c>No</c> <c>Yes</c><c>No</c> <c><xref target="RFC5150" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>6</c><c>Pre-Planned LSP Flag</c> <c>Yes</c> <c>No</c> <c>No</c> <c>No</c> <c><xref target="RFC6001" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>7</c><c>Non-PHP behavior flag</c> <c>Yes</c> <c>No</c> <c>Yes</c><c>No</c> <c><xref target="RFC6511" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>8</c><c>OOB mapping flag</c> <c>Yes</c> <c>No</c> <c>Yes</c><c>No</c> <c><xref target="RFC6511" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>9</c><c>Entropy Label Capability</c> <c>Yes</c> <c>Yes</c> <c>No</c> <c>No</c> <c><xref target="RFC6790" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>10</c><c>OAM MEP entities desired</c><c>Yes</c> <c>Yes</c> <c>Yes</c><c>No</c> <c><xref target="RFC7260" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>11</c><c>OAM MIP entities desired</c><c>Yes</c> <c>Yes</c> <c>Yes</c><c>No</c> <c><xref target="RFC7260" /></c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<!-- [RFC7260] -->
<c>12</c><c>SRLG collection Flag</c> <c>Yes</c> <c>Yes</c> <c>Yes</c><c>No</c> <c>[I.D.draft-</c>
<c> </c><c>(TEMPORARY - registered</c><c></c> <c></c> <c></c> <c></c> <c>ietf-teas-</c>
<c> </c><c>2014-09-11, expires</c> <c></c> <c></c> <c></c> <c></c> <c>rsvp-te-</c>
<c> </c><c>2015-09-11)</c> <c></c> <c></c> <c></c> <c></c> <c>srlg-collect]</c>
<c> </c><c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<!--<c></c> <c></c> <c></c> <c></c> <c></c> <c></c> <c><xref target="I-D.ietf-teas-rsvp-te-srlg-collect" /></c>-->
</texttable>
<t>
New allocation requests to this registry SHALL indicate the value to be used in the ERO column.
</t>
</section>
<section title="Existing LSP Attribute TLVs " anchor="IANA_ATTR">
<t>
IANA manages the "RSVP-TE PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-te-parameters/rsvp-te-parameters.xml.
The "Attributes TLV Space" registry manage the following attributes, as defined in <xref target="RFC5420" />:
<list style='symbols'>
<t>TLV Type (T-field value)</t>
<t>TLV Name</t>
<t>Whether allowed on LSP_ATTRIBUTES object</t>
<t>Whether allowed on LSP_REQUIRED_ATTRIBUTES object</t>
</list>
We request IANA to add the following information for each TLV in the RSVP TLV type identifier registry.
<list style='symbols'>
<t>Whether allowed on LSP Hop Attributes ERO subobject</t>
</list>
</t>
<t>
The existing registry is modified for existing TLVs as follows:
The following abbreviation are used in the table:
<list style='hanging'>
<t hangText="LSP_A"> Whether allowed on LSP_ATTRIBUTES object. </t>
<t hangText="LSP_RA"> Whether allowed on LSP_REQUIRED_ATTRIBUTES object.</t>
<t hangText="HOP_A"> Whether allowed on LSP Hop Attributes subobject.</t>
</list>
</t>
<texttable suppress-title='true' style='none'>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<ttcol align='left'></ttcol>
<c>T</c><c>Name</c> <c>LSP_A</c><c>LSP_RA</c><c>HOP_A</c><c>Ref.</c>
<c>-</c><c>---------------------</c><c>-----</c><c>------</c><c>-----</c><c>--------------</c>
<c>1</c><c>Attribute Flags</c> <c>Yes</c> <c>Yes</c> <c>Yes</c> <c><xref target="RFC5420" /></c>
<c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>2</c><c>Service ID TLV</c> <c>Yes</c> <c>No</c> <c>No</c> <c><xref target="RFC6060" /></c>
<c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
<c>3</c><c>OAM Configuration TLV</c><c>Yes</c> <c>Yes</c> <c>No</c> <c><xref target="RFC7260" /></c>
<c></c> <c></c> <c></c> <c></c> <c></c> <c>This Document</c>
</texttable>
</section>
</section> <!-- End IANA -->
<section title="Security Considerations">
<t>
This document adds new subobject in the EXPLICIT_ROUTE and the ROUTE_RECORD object carried in RSVP message used in MPLS and GMPLS signaling.
It builds on mechanism defined in <xref target="RFC3209" /> and <xref target="RFC5420"/> and does not introduce any new security. The
existing security considerations described in <xref target="RFC2205" />, <xref target="RFC3209"/>, <xref target="RFC3473" /> and <xref target="RFC5420" /> do apply.
</t>
<t>
As any RSVP-TE signaling request, the procedures defined in this document permit the transfer and reporting of functional preferences on specific node.
The mechanism added in this document does allow more control of LSP attributes at a given node. As other inputs, a node SHOULD check the Hop Attributes against his policies and admission procedures.
A node MAY reject the message using existing RSVP error code like "Policy Control Failure" or "Admission Control Failure". The node MAY also, depending on the specific TLV procedures, modify the requested attribute.
This can reveal information about the LSP request and status to anyone with unauthorized access. The mechanism described in this document do not contribute to this issue, which can be only resolved by encrypting the content of the whole signaling message.
</t>
<t>
In addition the reporting of attributes using the RRO can reveal details about the node that the operator wishes to remains confidential.
The same strategy and policies that apply to other RRO subobjects also apply to this new mechanism.
It is RECOMMENDED that domain boundary policies take the releasing of RRO hop attributes into consideration.
</t>
</section>
<section title="Acknowledgments">
<t>
The authors would like to thanks Lou Berger for his directions and Attila Takacs for inspiring this
<xref target="I-D.kern-ccamp-rsvpte-hop-attributes" />.
The authors also thanks Dirk Schroetter for his contribution to the initial versions of the documents (version -00 up to -02).
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3477.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4873.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4874.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4875.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4920.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5150.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5151.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5520.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5553.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5420.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6001.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6060.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6511.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6790.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7260.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4990.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6163.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-kern-ccamp-rsvpte-hop-attributes-00"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ccamp-wson-signaling-09"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-teas-rsvp-te-li-lb-04"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-teas-rsvp-te-srlg-collect-00"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ali-ccamp-rc-objective-function-metric-bound-05"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:27:15 |