One document matched: draft-ietf-ccamp-rsvp-te-srlg-collect-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml">
<!ENTITY RFC3473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3473.xml">
<!ENTITY RFC4202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4202.xml">
<!ENTITY RFC4206 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY RFC5150 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5150.xml">
<!ENTITY RFC5920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5920.xml">
<!ENTITY RFC6107 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6107.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-ccamp-rsvp-te-srlg-collect-02" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="RSVP-TE Ext for Collecting SRLG">RSVP-TE Extensions for Collecting SRLG Information</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Fatai Zhang" initials="F."
surname="Zhang" role="editor">
<organization>Huawei</organization>
<address>
<postal>
<street>F3-5-B RD Center</street>
<!-- Reorder these if your country does things differently -->
<city>Bantian, Longgang District</city>
<region>Shenzhen</region>
<code>518129</code>
<country> P.R.China</country>
</postal>
<phone></phone>
<email>zhangfatai@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dan Li" initials="D."
surname="Li" >
<organization>Huawei</organization>
<address>
<postal>
<street>F3-5-B RD Center</street>
<!-- Reorder these if your country does things differently -->
<city>Bantian, Longgang District</city>
<region>Shenzhen</region>
<code>518129</code>
<country> P.R.China</country>
</postal>
<phone></phone>
<email>danli@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Oscar Gonzalez de Dios" initials="O" role="editor"
surname="Gonzalez de Dios">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913328832</phone>
<email>ogondio@tid.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Cyril Margaria" initials="C."
surname="Margaria" >
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>St Martin Strasse 76</street>
<!-- Reorder these if your country does things differently -->
<city>Munich</city>
<region></region>
<code>81541</code>
<country>Germany</country>
</postal>
<phone>+49 89 5159 16934</phone>
<email>cyril.margaria@nsn.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Matt Hartley" initials="M."
surname="Hartley" >
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>mhartley@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>CCAMP</keyword>
<keyword>SRLG</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to support automatic collection of Shared Risk Link Group (SRLG) Information for the TE link formed by a LSP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>It is important to understand which TE links in the network might be at risk from the same failures. In this sense, a set of links may constitute a 'shared risk link group' (SRLG) if they share a resource whose failure may affect all links in the set <xref target="RFC4202"></xref>.</t>
<t>On the other hand, as described in <xref target="RFC4206"></xref> and <xref target="RFC6107"></xref>, H-LSP (Hierarchical LSP) or S-LSP (stitched LSP) can be used for carrying one or more other LSPs. Both of the H-LSP and S-LSP can be formed as a TE link. In such cases, it is important to know the SRLG information of the LSPs that will be used to carry further LSPs.</t>
<t>This document provides an automatic mechanism to collect the SRLG for the TE link formed by a LSP. Note that how to use the collected SRLG information is out of scope of this document</t>
</section>
<section title="RSVP-TE Requirements">
<section title="SRLG Collection Indication">
<t>The head nodes of the LSP must be capable of indicating whether the SRLG information of the LSP should be collected during the signaling procedure of setting up an LSP. SRLG information should not be collected without an explicit request for it being made by the head node.</t>
</section>
<section title="SRLG Collection">
<t>If requested, the SRLG information should be collected during the setup of an LSP. The endpoints of the LSP may use the collected SRLG information and use it for routing, sharing and TE link configuration purposes.</t>
</section>
<section title="SRLG Update">
<t>When the SRLG information of an existing LSP for which SRLG information was collected during signaling changes, the relevant nodes of the LSP must be capable of updating the SRLG information of the LSP. This means that that the signaling procedure must be capable of updating the new SRLG information.</t>
</section>
</section>
<section title="RSVP-TE Extensions (Encoding)">
<section title="SRLG Collection Flag">
<t>In order to indicate nodes that SRLG collection is desired, this document defines a new flag in the Attribute Flags TLV, which is carried in an LSP_REQUIRED_ATTRIBUTES or LSP_ATTRIBUTE Object:<list style="symbols">
<t>Bit Number (to be assigned by IANA, recommended bit 12): SRLG Collection flag</t>
</list></t>
<t>The SRLG Collection flag is meaningful on a Path message. If the SRLG Collection flag is set to 1, it means that the SRLG information should be reported to the head and tail node along the setup of the LSP.</t>
<t>The rules of the processing of the Attribute Flags TLV are not changed.</t>
</section>
<section title="SRLG sub-object">
<t>This document defines a new RRO sub-object (ROUTE_RECORD sub-object) to record the SRLG information of the LSP. Its format is modeled on the RRO sub-objects defined in <xref target="RFC3209">RFC 3209</xref>.</t>
<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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork></figure>
<t>Type</t>
<t>The type of the sub-object, to be assigned by IANA, which is recommended 34.</t>
<t>Length</t>
<t>The Length contains the total length of the sub-object in bytes, including the Type and Length fields. The Length depends on the number of SRLG IDs.</t>
<t>Flags</t>
<t>The Flags are used to indicate properties of the SRLG-list contained in the sub-object.</t>
<t><list>
<t>0x01 = SRLG-list edited</t>
<t>If set, this flag indicates that the SRLG-list contained in the RRO sub-object has been edited in some way by a node during signaling in accordance with that node's policy.</t>
<t>0x02 = Partial SRLG-list</t>
<t>If set, this flag indicates that the SRLG-list contained in this RRO sub-object is known to be incomplete.</t>
</list></t>
<t>SRLG Id</t>
<t>The 32-bit identifier of the SRLG.</t>
<t>Reserved</t>
<t>This field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.</t>
<t>The rules of the processing of the LSP_REQUIRED_ATTRIBUTES, LSP_ATTRIBUTE and ROUTE_RECORD Objects are not changed.</t>
</section>
</section>
<section title="Signaling Procedures">
<section title="SRLG Collection">
<t>Typically, the head node gets the route information of an LSP by adding a RRO which contains the sender’s IP addresses in the Path message. If a head node also desires SRLG recording, it sets the SRLG Collection Flag in the Attribute Flags TLV which can be carried either in an LSP_REQUIRED_ATTRIBUTES Object if the collection is mandatory, or in an LSP_ATTRIBUTES Object if the collection is desired, but not mandatory</t>
<t>When a node receives a Path message which carries an LSP_REQUIRED_ATTRIBUTES Object and the SRLG Collection Flag is set, if local policy determines that the SRLG information should not be provided to the endpoints, it MUST return a PathErr message with Error Code 2 (policy) and Error subcode "SRLG Recording Rejected" (value to be assigned by IANA, suggest value 108) to reject the Path message.</t>
<t>When a node receives a Path message which carries an LSP_ATTRIBUTES Object and the SRLG Collection Flag is set, if local policy determines that the SRLG information should not be provided to the endpoints, the Path message SHOULD NOT be rejected due to SRLG recording restriction and the Path message SHOULD be forwarded without the SRLG sub-object(s) in the Path RRO.</t>
<t>If local policy permits the recording of the SRLG information, the processing node SHOULD add an SRLG sub-object to the RRO to carry the local SRLG information. It then forwards the Path message to the next node in the downstream direction.</t>
<t>Following the steps described above, the intermediate nodes of the LSP can collect the SRLG information in the RRO during the forwarding of the Path message hop by hop. When the Path message arrives at the tail node, the tail node can get the SRLG information from the RRO.</t>
<t>Before the Resv message is sent to the upstream node, the tail node adds the SRLG subobject with the SRLG value(s) associated with the local hop to the Resv RRO in a similar manner to that specified above for the addition of Path RRO sub-objects by midpoint nodes.</t>
<t>When a node receives a Resv message for an LSP for which SRLG Collection is specified, if local policy determines that the SRLG information should not be provided to the endpoints, if the SRLG-recording request was in a LSP_REQUIRED_ATTRIBUTES object, then a ResvErr with Error code 2 (policy) and Error subcode "SRLG Recording Rejected" (value to be assigned by IANA, suggest value 108) MUST be sent. If the request was in a LSP_ATTRIBUTES object, then a ResvErr SHOULD NOT be generated, but SRLG information must not be added in the RRO. Otherwise, if local policy allows to provide the SRLG informatin, it MUST add an SRLG sub-object to the RRO to carry the SRLG information in the upstream direction. When the Resv message arrives at the head node, the head node can get the SRLG information from the RRO in the same way as the tail node.</t>
<t>Note that a link’s SRLG information for the upstream direction cannot be assumed to be the same as that in the downstream.</t>
<t><list style="symbols">
<t>For Path and Resv messages for a unidirectional LSP, a node SHOULD include SRLG sub-objects in the RRO for the downstream data link only.</t>
<t>For Path and Resv messages for a bidirectional LSP, a node SHOULD include SRLG sub-objects in the RRO for both the upstream data link and the downstream data link from the local node. In this case, the node MUST include the information in the same order for both Path messages and Resv messages. That is, the SRLG sub-object for the upstream link is added to the RRO before the SRLG sub-object for the downstream link.</t>
</list>
</t>
<t>Based on the above procedure, the endpoints can get the SRLG information automatically. Then the endpoints can for instance advertise it as a TE link to the routing instance based on the procedure described in <xref target="RFC6107"/> and configure the SRLG information of the FA automatically.</t>
<t>It is noted that a node (e.g. the edge node of a domain) may edit the RRO to remove the route information (e.g. node, interface identifier information) before forwarding it due to some reasons (e.g.confidentiality or reduce the size of RRO). A node MAY edit SRLG
information within the RRO of a Path or Resv message if dictated by its local policy. If a node makes such an alteration to an existing
RRO object, it SHOULD set the "SRLG-list edited" flag in the edited RRO sub-object to indicate to other nodes that this has been done.</t>
</section>
<section title="SRLG Update">
<t>When the SRLG information of a link is changed, the LSPs using that link should be aware of the changes. The procedures defined in Section 4.4.3 of <xref target="RFC3209">RFC 3209</xref> MUST be used to refresh the SRLG information if the SRLG change is to be communicated to other nodes according to the local node's policy. If local policy is that the SRLG change should be suppressed or would result in no change to the previously signaled SRLG-list, the node need not send an update</t>
</section>
</section>
<section title="Manageability Considerations">
<section title="Policy Configuration ">
<t>In a border node of inter-domain or inter-layer network, the following SRLG processing policy should be capable of being configured:<list style="symbols">
<t>Whether the SRLG IDs of the domain or specific layer network can be exposed to the nodes outside the domain or layer network, or whether they should be summarized or removed entirely.</t>
<t>If SRLGs are summarized or removed, whether the "SRLG-list edited" flag is set in affected SRLG RRO-sub-objects and .</t>
<t>If SRLGs are summarized or removed, whether the "SRLG-list edited" and "Partial SRLG-list" flags are set in affected SRLG RRO-sub-objects.</t>
</list>
</t>
</section>
<section title="Coherent SRLG IDs">
<t>In a multi-layer multi-domain scenario, SRLG ids may be configured by different management entities in each layer/domain. In such scenarios, maintaining a coherent set of SRLG IDs is a key requirement in order to be able to use the SRLG information properly. Thus, SRLG IDs must be unique. Note that current procedure is targeted towards a scenario where the different layers and domains belong to the same operator, or to several coordinated administrative groups. Ensuring the aforementioned coherence of SRLG IDs is beyond the scope of this documen</t>
<t>Further scenarios, where coherence in the SRLG IDs cannot be guaranteed are out of the scope of the present document and are left for further study.</t>
</section>
</section>
<section title="Security Considerations">
<t>This document does not introduce any additional security issues above those identified in <xref target="RFC5920"/><xref target="RFC3209"/><xref target="RFC3473"/></t>
</section>
<section title="IANA Considerations">
<section title="RSVP Attribute Bit Flags">
<t>IANA has created a registry and manages the space of attributes bit flags of Attribute Flags TLV as described in section 11.3 of [RFC5420]. It is requested that IANA makes assignments from the Attribute Bit Flags. </t>
<t>This document introduces a new Attribute Bit Flag: <list style="symbols">
<t>Bit number: TBD (12)</t>
<t>Defining RFC: this I-D</t>
<t>Name of bit: SRLG Collection Flag</t>
<t>The meaning of the Attribute Flags TLV on a Path is defined in this I-D</t></list></t>
</section>
<section title="ROUTE_RECORD Object">
<t>IANA has made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. We request that IANA make assignments from the ROUTE_RECORD <xref target="RFC3209">RFC 3209</xref> portions of this registry.</t>
<t>This document introduces a new RRO sub-object:</t>
<figure><artwork><![CDATA[
Type Name Reference
--------- ---------------------- ---------
TBD (34) SRLG sub-object This I-D]]></artwork></figure>
<section title="SRLG sub-object Flags">
<t> It is requested that the IANA ceates a registry to manage the space of bit flags of the SRLG sub-object defined in this document. It is requested that IANA makes assignments from the SRLG sub-object Flags. </t>
<t>This document introduces two new SRLG sub-object Flags.</t>
<texttable>
<ttcol align="center">Bit Number</ttcol> <ttcol align="center">Name</ttcol> <ttcol align="center">Reference</ttcol>
<c>1</c> <c>SRLG-list edited</c> <c>This document</c>
<c>2</c> <c>Partial SRLG-list</c> <c>This document</c>
</texttable>
</section>
</section>
<section title="Policy Control Failure Error subcodes">
<t>IANA has made the following assignments in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters. We request that IANA make assignments from the Policy Control Failure Sub-Codes registry.</t>
<t>This document introduces a new Policy Control Failure Error sub-code:<list style="symbols">
<t>Error sub-code: TBD (108)</t>
<t>Defining RFC: this I-D</t>
<t>Name of error sub-code: SRLG Recording Rejected</t>
<t>The meaning of the SRLG Recording Rejected error sub-code is defined in this I-D</t></list></t>
</section>
</section>
<!-- ===================================================================
CONTRIBUTING AUTHORS
=================================================================== -->
<section title="Contributing Authors">
<t>
<list>
<t>
Zafar Ali<vspace blankLines='0'/>
Cisco Systems<vspace blankLines='0'/>
zali@cisco.com<vspace blankLines='0'/>
</t>
</list>
</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to thank Igor Bryskin, Ramon Casellas, Lou Berger and Alan Davey for their useful comments and improvements to the document.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC3209;
&RFC3473;
&RFC4202;
&RFC4206;
&RFC5150;
&RFC5920;
&RFC6107;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 17:12:34 |