One document matched: draft-ietf-mpls-tp-ethernet-addressing-05.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-05"
ipr="trust200902">
<front>
<title abbrev="MPLS-TP Ethernet Addressing">MPLS-TP Next-Hop Ethernet
Addressing</title>
<author fullname="Dan Frost" initials="D" surname="Frost">
<organization>Cisco Systems</organization>
<address>
<email>danfrost@cisco.com</email>
</address>
</author>
<author fullname="Stewart Bryant" initials="S" surname="Bryant">
<organization>Cisco Systems</organization>
<address>
<email>stbryant@cisco.com</email>
</address>
</author>
<author fullname="Matthew Bocci" initials="M" surname="Bocci">
<organization>Alcatel-Lucent</organization>
<address>
<email>matthew.bocci@alcatel-lucent.com</email>
</address>
</author>
<date year="2013" />
<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>
<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>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>
</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
Link Layer Discovery Protocol (LLDP) <xref target="LLDP"></xref> is in
use, 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" (TBD1), 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; the
TLV format is as defined in <xref
target="I-D.ietf-mpls-gach-adv"></xref>:<list style="empty">
<t>Source MAC Address (type = 0, length = 8): The Value of this
object is an EUI-64 <xref target="EUI-64"></xref> unicast MAC
address assigned to one of the interfaces of the sender that is
connected to this data link. The IEEE-defined mapping from 48-bit
MAC addresses to EUI-64 form is used.</t>
<t>MTU (type = 1, length = 4): 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>Where MAC address learning occurs by some other means, this TLV
group MAY be used to advertise only the MTU. If multiple adverisements
are made for the the same parameter, use of these advertisments is
undefined.</t>
<t>In the event of the persistent loss of the GAP messages, the
receiving node MUST assume that it is now connected to a node that does
not support these advertisements and must behave as configured for this
eventuality.</t>
</section>
<section title="Manageability Considerations">
<t>The values sent and received by this protocol MUST be made accessible
for inspection by network operators, and where local configuration is
updated by the received information, it MUST be clear why the configured
value has been changed. The advertised information SHOULD be persistent
across restarts. Received advertisements MUST be discarded across
restarts. If the received values change, the new values MUST be used and
the change made visible to the network operators.</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>
<t>An attacker could disrupt communications by modifying the Source MAC
Address or the MTU values, however this is mitigated by the use of
cryptographic authetication as described in <xref
target="I-D.ietf-mpls-gach-adv"></xref> which also describes other
considerations applicable to the GAP protocol. Visibility into the
contents of either of the TLVs could provide information that is useful
for an attacker. This is best addressed by physical security of the
links.</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. IANA is requested to update the reference to point
to the RFC number assigned to this document.</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>TBD1 to be assigned by IANA</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>
<section title="Acknowledgements">
<t>We thank Adrian Farrel for his valuable review comments on this
document.</t>
</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.3032'?>
<?rfc include='reference.RFC.5654'?>
<?rfc include='reference.RFC.5332'?>
<?rfc include='reference.RFC.5960'?>
<reference anchor="EUI-64">
<front>
<title>[EUI64] IEEE, "Guidelines for 64-bit Global Identifier
(EUI-64) Registration Authority",
http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March
1997.</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="LLDP">
<front>
<title>IEEE, "Station and Media Access Control Connectivity
Discovery (802.1AB)", September 2009.</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.0826'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.5921'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:32:37 |