One document matched: draft-ietf-mpls-tp-ethernet-addressing-03.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="no"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mpls-tp-ethernet-addressing-03"
     ipr="trust200902">
  <front>
    <title abbrev="MPLS-TP Ethernet Addressing">MPLS-TP Next-Hop Ethernet
    Addressing</title>

    <author fullname="Dan Frost" initials="D" role="editor" surname="Frost">
      <organization>Cisco Systems</organization>

      <address>
        <email>danfrost@cisco.com</email>
      </address>
    </author>

    <author fullname="Stewart Bryant" initials="S" role="editor"
            surname="Bryant">
      <organization>Cisco Systems</organization>

      <address>
        <email>stbryant@cisco.com</email>
      </address>
    </author>

    <author fullname="Matthew Bocci" initials="M" role="editor"
            surname="Bocci">
      <organization>Alcatel-Lucent</organization>

      <address>
        <email>matthew.bocci@alcatel-lucent.com</email>
      </address>
    </author>

    <date year="2012" />

    <area>Routing</area>

    <workgroup>MPLS</workgroup>

    <keyword>MPLS</keyword>

    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP)
      is the set of MPLS protocol functions applicable to the construction and
      operation of packet-switched transport networks. This document presents
      considerations for link-layer addressing of Ethernet frames carrying
      MPLS-TP packets.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The MPLS Transport Profile (MPLS-TP) <xref target="RFC5921"></xref>
      is the set of protocol functions that meet the requirements <xref
      target="RFC5654"></xref> for the application of MPLS to the construction
      and operation of packet-switched transport networks. The MPLS-TP data
      plane consists of those MPLS-TP functions concerned with the
      encapsulation and forwarding of MPLS-TP packets and is described in
      <xref target="RFC5960"></xref>.</t>

      <t>This document presents considerations for link-layer addressing of
      Ethernet frames carrying MPLS-TP packets. Since MPLS-TP packets are MPLS
      packets, existing procedures (<xref target="RFC3032"></xref>, <xref
      target="RFC5332"></xref>) for the encapsulation of MPLS packets over
      Ethernet apply. Because IP functionality is optional in an MPLS-TP
      network, however, IP-based protocols for Media Access Control (MAC)
      address learning, such as the Address Resolution Protocol (ARP) <xref
      target="RFC0826"></xref> and IP version 6 Neighbor Discovery <xref
      target="RFC4861"></xref>, may not be available. This document specifies
      the options for determination and selection of next-hop Ethernet MAC
      addressing under these circumstances.</t>

      <t>This document is a product of a joint Internet Engineering Task Force
      (IETF) / International Telecommunication Union Telecommunication
      Standardization Sector (ITU-T) effort to include an MPLS Transport
      Profile within the IETF MPLS and PWE3 architectures to support the
      capabilities and functionalities of a packet transport network.</t>

      <section title="Terminology">
        <texttable align="left" style="headers">
          <ttcol>Term</ttcol>

          <ttcol>Definition</ttcol>

          <c>ARP</c>

          <c>Address Resolution Protocol</c>

          <c>G-ACh</c>

          <c>Generic Associated Channel</c>

          <c>GAL</c>

          <c>G-ACh Label</c>

          <c>LSP</c>

          <c>Label Switched Path</c>

          <c>LSR</c>

          <c>Label Switching Router</c>

          <c>MAC</c>

          <c>Media Access Control</c>

          <c>MPLS-TP</c>

          <c>MPLS Transport Profile</c>

          <c>OAM</c>

          <c>Operations, Administration, and Maintenance</c>
        </texttable>

        <t>Additional definitions and terminology can be found in <xref
        target="RFC5960"></xref> and <xref target="RFC5654"></xref>.</t>
      </section>

      <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"></xref>.</t>
      </section>
    </section>

    <section anchor="eth-p2p" title="Point-to-Point Link Addressing">
      <t>When two MPLS-TP nodes are connected by a point-to-point Ethernet
      link, the question arises as to what destination Ethernet Media Access
      Control (MAC) address should be specified in Ethernet frames transmitted
      to the peer node over the link. The problem of determining this address
      does not arise in IP/MPLS networks because of the presence of the
      Ethernet Address Resolution Protocol (ARP) <xref
      target="RFC0826"></xref> or IP version 6 Neighbor Discovery protocol
      <xref target="RFC4861"></xref>, which allow the unicast MAC address of
      the peer device to be learned dynamically.</t>

      <t>If existing mechanisms are available in an MPLS-TP network to
      determine the destination unicast MAC addresses of peer nodes -- for
      example, if the network also happens to be an IP/MPLS network, or if it
      implements the procedures in <xref target="gap"></xref> of this document
      -- such mechanisms SHOULD be used. The remainder of this section
      discusses the available options when this is not the case.</t>

      <t>Each node MAY be statically configured with the MAC address of its
      peer. Note however that static MAC address configuration can present an
      administrative burden and lead to operational problems. For example,
      replacement of an Ethernet interface to resolve a hardware fault when
      this approach is used requires that the peer node be manually
      reconfigured with the new MAC address. This is especially problematic if
      the peer is operated by another provider.</t>

      <t>Another approach which may be considered is to use the Ethernet
      broadcast address FF-FF-FF-FF-FF-FF as the destination MAC address in
      frames carrying MPLS-TP packets over a link that is known to be
      point-to-point. This may, however, lead to excessive frame distribution
      and processing at the Ethernet layer. Broadcast traffic may also be
      treated specially by some devices and this may not be desirable for
      MPLS-TP data frames.</t>

      <t>In view of the above considerations, the approach which SHOULD be
      used, is therefore to configure both nodes to use the method described
      in this document which uses, as a destination MAC address, an Ethernet
      multicast address reserved for MPLS-TP for use over point-to-point
      links. The address allocated for this purpose by the Internet Assigned
      Numbers Authority (IANA) is 01-00-5E-90-00-00. An MPLS-TP implementation
      MUST process Ethernet frames received over a point-to-point link with
      this destination MAC address by default.</t>

      <t>The use of broadcast or multicast addressing for the purpose
      described in this section, i.e. as a placeholder for the unknown unicast
      MAC address of the destination, is applicable only when the attached
      Ethernet link is known to be point-to-point. If a link is not known to
      be point-to-point, these forms of addressing MUST NOT be used. Thus the
      implementation MUST provide a means for the operator to declare that a
      link is point-to-point if it supports these addressing modes. Moreover,
      the operator is cautioned that it is not always clear whether a given
      link is, or will remain, strictly point-to-point, particularly when the
      link is supplied by an external provider; point-to-point declarations
      must therefore be used with care. Because of these caveats it is
      RECOMMENDED that implementations support the procedures in <xref
      target="gap"></xref> so that unicast addressing can be used.</t>
    </section>

    <section title="Multipoint Link Addressing">
      <t>When a multipoint Ethernet link serves as a section <xref
      target="RFC5960"></xref> for a point-to-multipoint MPLS-TP LSP, and
      multicast destination MAC addressing at the Ethernet layer is used for
      the LSP, the addressing and encapsulation procedures specified in <xref
      target="RFC5332"></xref> SHALL be used.</t>

      <t>When a multipoint Ethernet link -- that is, a link which is not known
      to be point-to-point -- serves as a section for a point-to-point MPLS-TP
      LSP, unicast destination MAC addresses MUST be used for Ethernet frames
      carrying packets of the LSP. According to the discussion in the previous
      section, this implies the use of either static MAC address configuration
      or a protocol that enables peer MAC address discovery.</t>
    </section>

    <section anchor="gap"
             title="MAC Address Discovery via the G-ACh Advertisement Protocol">
      <t>The G-ACh Advertisement Protocol (GAP) <xref
      target="I-D.ietf-mpls-gach-adv"></xref> provides a simple means of
      informing listeners on a link of the sender's capabilities and
      configuration. When used for this purpose on an Ethernet link, GAP
      messages are multicast to the address 01-00-5e-80-00-0d. If these
      messages contain the unicast MAC address of the sender, then listeners
      can learn this address and use it in the future when transmitting frames
      containing MPLS-TP packets. Since the GAP does not rely on IP, this
      provides a means of unicast MAC discovery for MPLS-TP nodes without IP
      support.</t>

      <t>This document defines a new GAP application, "Ethernet Interface
      Parameters", to support the advertisement of Ethernet-specific
      parameters associated with the sending interface. The following
      Type-Length-Value (TLV) objects are defined for this application: <list
          style="empty">
          <t>Source MAC Address: The Value of this object is a 48-bit Ethernet
          unicast MAC address in canonical form <xref target="RFC2469"></xref>
          assigned to one of the interfaces of the sender that is connected to
          this data link.</t>

          <t>MTU: The Value of this object is a 32-bit unsigned integer
          encoded in network byte order that specifies the maximum
          transmission unit size of the sending interface, in octets.</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>The use of broadcast or multicast Ethernet destination MAC addresses
      for frames carrying MPLS-TP data packets can potentially result in such
      frames being distributed to devices other than the intended destination
      node or nodes when the Ethernet link is not point-to-point. The operator
      SHOULD take care to ensure that MPLS-TP nodes are aware of the Ethernet
      link type (point-to-point or multipoint). In the case of multipoint
      links, the operator SHOULD either ensure that no devices are attached to
      the link that are not authorized to receive the frames, or take steps to
      mitigate the possibility of excessive frame distribution, for example by
      configuring the Ethernet switch to appropriately restrict the delivery
      of multicast frames to authorized ports.</t>
    </section>

    <section title="IANA Considerations">
      <section title="Ethernet Multicast Address Allocation">
        <t>IANA has allocated an Ethernet multicast address from the "IANA
        Multicast 48-bit MAC Addresses" address block in the "Ethernet
        Numbers" registry for use by MPLS-TP LSRs over point-to-point links as
        described in <xref target="eth-p2p"></xref>. The allocated address is
        01-00-5E-90-00-00.</t>
      </section>

      <section title="G-ACh Advertisement Protocol Allocation">
        <t>IANA is requested to allocate a new Application ID in the "G-ACh
        Advertisement Protocol Applications" registry <xref
        target="I-D.ietf-mpls-gach-adv"></xref> (currently located in the
        "Pseudowire Name Spaces (PWE3)"), as follows:</t>

        <texttable align="left" style="headers">
          <ttcol>Application ID</ttcol>

          <ttcol>Description</ttcol>

          <ttcol>Reference</ttcol>

          <c>0x0001</c>

          <c>Ethernet Interface Parameters</c>

          <c>(this draft)</c>
        </texttable>
      </section>

      <section title="Creation of Ethernet Interface Parameters Registry">
        <t>IANA is requested to create a new registry, "G-ACh Advertisement
        Protocol: Ethernet Interface Parameters" within the "Pseudowire Name
        Spaces (PWE3)" with fields and initial allocations as follows:</t>

        <texttable align="left" style="headers">
          <ttcol>Type Name</ttcol>

          <ttcol>Type ID</ttcol>

          <ttcol>Reference</ttcol>

          <c>Source MAC Address</c>

          <c>0</c>

          <c>(this draft)</c>

          <c>MTU</c>

          <c>1</c>

          <c>(this draft)</c>
        </texttable>

        <t>The range of the Type ID field is 0 - 255.</t>

        <t>The allocation policy for this registry is IETF Review.</t>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.I-D.ietf-mpls-gach-adv'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2469'?>

      <?rfc include='reference.RFC.3032'?>

      <?rfc include='reference.RFC.5654'?>

      <?rfc include='reference.RFC.5332'?>

      <?rfc include='reference.RFC.5960'?>
    </references>

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

      <?rfc include='reference.RFC.4861'?>

      <?rfc include='reference.RFC.5921'?>
    </references>
  </back>
</rfc>