One document matched: draft-xu-spring-islands-connection-over-ip-05.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="info" docName="draft-xu-spring-islands-connection-over-ip-05"
ipr="trust200902">
<front>
<title abbrev="">Connecting MPLS-SPRING Islands over IP Networks</title>
<author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
<organization>Huawei</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>xuxiaohu@huawei.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Robert Raszuk" initials="R.R." surname="Raszuk">
<organization>Bloomberg LP</organization>
<address>
<email>robert@raszuk.net</email>
</address>
</author>
<author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
<organization>Ericsson</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>uma.chunduri@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Luis M. Contreras" initials="L.M." surname="Contreras">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Ronda de la Comunicacion, s/n</street>
<street>Sur-3 building, 3rd floor</street>
<city>Madrid,</city>
<code>28050</code>
<country>Spain</country>
</postal>
<email>luismiguel.contrerasmurillo@telefonica.com</email>
<uri>http://people.tid.es/LuisM.Contreras/</uri>
</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>Soham</city>
<region></region>
<code></code>
<country>UK</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 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 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>
<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"/>,
<xref target="I-D.ietf-spring-segment-routing-mpls"/> and <xref
target="I-D.xu-sfc-using-mpls-spring"/> .</t>
</section>
<section anchor="Procedure" title="Packet Forwarding Procedures">
<t>Assume an MPLS-SPRING-enabled router X prepares to forward an MPLS
packet to the next 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. 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
top label to the corresponding label significant to Y and then
encapsulate the MPLS packet into an IP-based tunnel. 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 top label is a PHP label and not at the bottom
of the label stack, X SHOULD pop that top label before performing the
above encapsulation. The IP encapsulated packet would be forwarded
according to the IP forwarding table. Upon receipt of that IP
encapsulated packet, Y would decapsulate it and then process the
decapsulated MPLS packet accordingly.</t>
<t>As for which tunnel encapsulation type should be used by X, it can be
manually specified on X or 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 action is required for IANA.</t>
<!---->
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD.</t>
<!---->
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
<?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>
<?rfc include="reference.RFC.3031"?>
<!---->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4023"
?>
<?rfc include="reference.RFC.4817"?>
<?rfc include="reference.RFC.7510"?>
<?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.xu-isis-encapsulation-cap"?>
<?rfc include="reference.I-D.ietf-ospf-encapsulation-cap"?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:59:20 |