One document matched: draft-xu-spring-islands-connection-over-ip-03.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-spring-islands-connection-over-ip-03"
     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>Mirantis Inc.</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>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>

    <!--

-->

    <date year="2014"/>

    <abstract>
      <t>MPLS-SPRING is a 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. The current MPLS-SRPING architecture requires an end-to-end MPLS
      Label Switched Path (LSP) between any two MPLS-SPRING-enabled routers
      (e.g., two adjacent hops of a given explicit path). In order to enable
      MPLS-SPRING-enabled routers to be deployed even when there are non-MPLS
      routers along the path between two MPLS-SPRING-enabled routers, it is
      desirable to have an alternative, which allows the use of IP-based
      tunnels (e.g., GRE tunnels) to connect two MPLS-SPRING-enabled routers.
      This document describes a mechanism for such usage.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>MPLS-SPRING <xref target="I-D.ietf-spring-segment-routing-mpls"/> is
      a 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. The current
      MPLS-SRPING architecture requires an end-to-end MPLS Label Switched Path
      (LSP) between any two MPLS-SPRING-enabled routers (e.g., two adjacent
      hops of a given explicit path). In order to enable MPLS-SPRING-enabled
      routers to be deployed even when there are non-MPLS routers along the
      path between two MPLS-SPRING-enabled routers, it is desirable to have an
      alternative, which allows the use of IP-based tunnels (e.g.,
      MPLS-in-IP/GRE tunnel <xref target="RFC4023"/>, MPLS-in-L2TPv3 tunnel
      <xref target="RFC4817"/> or MPLS-in-UDP tunnel <xref
      target="I-D.ietf-mpls-in-udp"/>) to connect two MPLS-SPRING-enabled
      routers which are specified as adjacent hops of a given explicit path.
      The tunnel destination address would be the address of next-hop
      MPLS-SPRING-enabled router along the explicit path, and this would cause
      the packet to be delivered to the next explicit hop. In this procedure,
      the ingress and egress of the IP-based tunnel MUST support MPLS-SPRING
      features including the MPLS forwarding capability, whereas those transit
      routers along the path between them don't need to support any
      MPLS-SPRING features including the MPLS forwarding capability. The above
      mechanism is much useful for incrementally deployment of the MPLS-SPRING
      technology, especially in the MPLS-SPRING-based Service Function
      Chainning (SFC) case where only a few specific routers (e.g., service
      nodes and classifiers) are actually required to be
      MPLS-SPRING-capable.</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="I-D.ietf-spring-segment-routing-mpls"/>.</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 explicit hop Y which is identified by the top label
      of the MPLS packet, if the next-hop router Z which is physically
      adjacent to X is a non-MPLS-SPRING router, X would encapsulate the MPLS
      packet into an IP-based tunnel (e.g., GRE tunnel or UDP tunnel) where
      the tunnel destination is an IP address of Y (i.e., the /32 or /128 IGP
      prefix FEC corresponding to that top label) and the tunnel source is an
      IP address of X. If the top label is a Penultimate Hop Popping (PHP)
      label, X SHOULD pop that top label before performing the 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 dynamically learnt from Y's advertisement of
      its tunnel encapsulation capability. How to advertise the tunnel
      encapsulation capability is outside of the scope of this document.</t>
    </section>

    <!---->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks Joel Halpern for his 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"?>

      <!---->
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4023"
?>

      <?rfc include="reference.RFC.4817"?>

      <?rfc include="reference.I-D.ietf-mpls-in-udp"?>

      <!---->
    </references>
  </back>
</rfc>