One document matched: draft-xu-mpls-spring-islands-connection-over-ip-00.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 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-xu-mpls-spring-islands-connection-over-ip-00"
ipr="trust200902">
<front>
<title abbrev="">Connecting MPLS-SPRING Islands over IP Networks</title>
<author fullname="Xiaohu Xu" initials="X.X." role="editor" surname="Xu">
<organization>Huawei</organization>
<address>
<email>xuxiaohu@huawei.com</email>
</address>
</author>
<author fullname="Robert Raszuk" initials="R.R." surname="Raszuk">
<organization>Bloomberg LP</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>robert@raszuk.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
<organization/>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Bangalore</city>
<region></region>
<code></code>
<country>India</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>uma.chunduri@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Luis M. Contreras" initials="L.C." surname="Contreras">
<organization>Telefonica I+D</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Bangalore</city>
<region></region>
<code></code>
<country>India</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>luismiguel.contrerasmurillo@telefonica.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Luay Jalil" initials="L.J." surname="Jalil">
<organization>Verizon</organization>
<address>
<!--
<postal>
<street></street>
-->
<!-- Reorder these if your country does things differently -->
<!--
<city>Bangalore</city>
<region></region>
<code></code>
<country>India</country>
</postal>
<phone>+44 7889 488 335</phone>
-->
<email>luay.jalil@verizon.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!--
-->
<date day="" month="" year="2016"/>
<abstract>
<t>MPLS-SPRING is an MPLS-based source routing paradigm in which a
sender of a packet is allowed to partially or completely specify the
route the packet takes through the network by imposing stacked MPLS
labels to the packet. To facilitate the incremental deployment of this
new technology, this document describes a mechanism which allows the
outermost LSP be replaced by an IP-based tunnel.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>MPLS-SPRING <xref target="I-D.ietf-spring-segment-routing-mpls"/> is
a MPLS-based source routing paradigm in which a sender of a packet is
allowed to partially or completely specify the route the packet takes
through the network by imposing stacked MPLS labels to the packet. To
facilitate the incremental deployment of this new technology, this
document describes a mechanism which allows the outermost LSP to be
replaced by an IP-based tunnel (e.g., MPLS-in-IP/GRE tunnel <xref
target="RFC4023"/>, MPLS-in-UDP tunnel <xref target="RFC7510"/> or
MPLS-in-L2TPv3 tunnel <xref target="RFC4817"/> and etc) when the nexthop
along the LSP is not MPLS-SPRING- enabled. The tunnel destination
address would be the address of the egress of the outmost LSP (e.g., the
egress of the active node segment).</t>
<t>This mechanism is much useful in the MPLS-SPRING-based Service
Function Chainning (SFC) case <xref
target="I-D.xu-sfc-using-mpls-spring"/> where only a few specific
routers (e.g., Service Function Forwarders (SFF) and classifiers) are
required to be MPLS-SPRING-capable while the remaining routers are just
required to support IP forwarding capability. In addition, this
mechanism is also useful in some specific Traffic Engineering scenarios
where only a few routers (e.g., the entry and exit nodes of each plane
in the dual-plane network ) are specified as segments of explicit paths.
In this way, only a few routers are required to support the MPLS-SPRING
capability while all the other routers just need to support IP
forwarding capability, which would significantly reduce the deployment
cost of this new technology. Furthermore, since there is no need to run
any other label distribution protocol (e.g., LDP), the network
provisioning is greatly simplified, which is one of the major claimed
benefits of the MPLS-SPRING technology.</t>
<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 anchor="Abbreviations_Terminology" title="Terminology">
<t>This memo makes use of the terms defined in <xref target="RFC3031"/>
and <xref target="I-D.ietf-spring-segment-routing-mpls"/>.</t>
</section>
<section title="Packet Forwarding Procedures">
<t>Assume an MPLS-SPRING-enabled router X prepares to forward an MPLS
packet to the next node segment (i.e., the node segment of MPLS-SPRING-
enabled router Y) which is identified by the top label of the MPLS
packet. If the next-hop router of the best path to Y is a non-MPLS
router, X couldn't map the packet's top label into an Next Hop Label
Forwarding Entry (NHLFE) , even though the top label itself is a valid
incoming label. Acorrding to the following specification as quoted from
Section 3.22 of <xref target="RFC3031"/>, the MPLS packet would be
discarded in the currenet MPLS implementations:</t>
<t><list style="empty">
<t>"When a labeled packet is traveling along an LSP, it may
occasionally happen that it reaches an LSR at which the ILM does not
map the packet's incoming label into an NHLFE, even though the
incoming label is itself valid...Unless it can be determined
(through some means outside the scope of this document) that neither
of these situations obtains, the only safe procedure is to discard
the packet. "</t>
</list>This document proposes an improved procedure to deal with the
above case. The basic idea is to set an IP tunnel towards the egress of
topmost LSP as the NHLFE of that incoming label. More specifically, if
the label is not a Penultimate Hop Popping (PHP) label (i.e., the
NP-flag <xref target="I-D.ietf-isis-segment-routing-extensions"/>
associated with the corresponding prefix SID of that top label is set),
X SHOULD swap the label to the corresponding label significant to Y and
then encapsulate the MPLS packet into the IP-based tunnel towards Y. The
tunnel destination address is the IP address of Y (e.g., the /32 or /128
prefix FEC associated with that top label) and the tunnel source address
is the IP address of X. If the label is a PHP label and not at the
bottom of the label stack, X SHOULD pop that label before performing the
above MPLS over IP encapsulation. The IP encapsulated MPLS packet would
be forwarded according to the IP routing table. Upon receipt of that IP
encapsulated MPLS packet, Y would decapsulate it and then process the
decapsulated MPLS packet accordingly. As for which tunnel encapsulation
type should be used by X, it can be manually specified on X or be learnt
from Y's advertisement of its tunnel encapsulation capability. How to
advertise the tunnel encapsulation capability using IS-IS or OSPF are
specified in <xref target="I-D.xu-isis-encapsulation-cap"/> and <xref
target="I-D.ietf-ospf-encapsulation-cap"/> respectively.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks Joel Halpern, Bruno Decraene and Loa Andersson for their
insightful comments on this draft.</t>
<!---->
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No IANA action is required.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD.</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<!---->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3031"?>
<?rfc include="reference.RFC.4817"?>
<?rfc include="reference.RFC.7510"?>
<?rfc include="reference.RFC.4023"?>
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>
<?rfc include="reference.I-D.ietf-isis-segment-routing-extensions"?>
<?rfc include="reference.I-D.xu-sfc-using-mpls-spring"?>
<?rfc include="reference.I-D.ietf-ospf-encapsulation-cap"?>
<?rfc include="reference.I-D.xu-isis-encapsulation-cap"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:18:16 |