Internet DRAFT - draft-eastlake-trill-lldp
draft-eastlake-trill-lldp
Network Working Group Donald Eastlake
INTERNET-DRAFT Huawei
Updates: 6325 Anoop Ghanwani
Intended status: Proposed Standard Dell
Expires: March 11, 2012 September 12, 2012
Transparent Interconnection of Lots of Links (TRILL)
Support of the Link Layer Discover Protocol (LLDP)
<draft-eastlake-trill-lldp-01.txt>
Abstract
RBridges are devices that implement the IETF TRILL (Transparent
Interconnection of Lots of Links, RFC 6325) protocol. The Link Layer
Discovery Protocol (LLDP, IEEE Std 802.1AB) is a one-way,
unacknowledged protocol for the announcement of a station's
capabilities to its peers. The set of peers that receive these
frames and the scoping of the frame is primarily determined by the
destination MAC address of the LLDP frame. This document specifies a
Nearest-RBridge MAC address and other details of TRILL support of
LLDP. It updates RFC 6325.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the authors.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
D. Eastlake [Page 1]
INTERNET-DRAFT LLDP Support in TRILL
Table of Contents
1. Introduction............................................3
1.1 Terminology and Acronyms...............................3
2. LLDP on RBridge Ports...................................4
2.1 Use on Ethernet Ports..................................4
2.2 Use on Other RBridge Ports.............................5
3. Nearest-RBridge as Inner.MacDA..........................6
3.1 Transmission...........................................6
3.2 Receipt................................................6
4. Change in RFC 6325......................................8
5. IANA Considerations.....................................8
6. Security Considerations.................................8
Normative References.......................................9
Informative References.....................................9
D. Eastlake [Page 2]
INTERNET-DRAFT LLDP Support in TRILL
1. Introduction
The Link Layer Discovery Protocol (LLDP [802.1AB]) is a one-way,
unacknowledged protocol for the announcement of a station's
capabilities to its peers. The set of peers that receive these
frames and the scoping of the frame is primarily determined by the
destination address of the LLDP frame. This document specifies TRILL
(Transparent Interconnection of Lots of Links, [RFC6325] [RFC6327])
support of LLDP. Such support is optional. This document updates
[RFC6325].
Clause 7.1 of the IEEE [802.1AB] Standard provides that LLDP may be
used with any unicast or group (multi-destination) destination
address. This document specifies the Nearest-RBridge MAC destination
address.
1.1 Terminology and Acronyms
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 [RFC2119].
The following are used in this document:
IEEE - Institute for Electronic and Electrical Engineers
(www.ieee.org)
LLDP - Link Layer Discovery Protocol [802.1AB]
LLDPDU - LLDP Data Unit [802.1AB]
MAC - Media Access Control [802]
RBridge - Routing Bridge [RFC6325]
TPMR - Two Port MAC Relay [802.1Q]
TRILL - Transparent Interconnection of Lots of Links [RFC6325]
D. Eastlake [Page 3]
INTERNET-DRAFT LLDP Support in TRILL
2. LLDP on RBridge Ports
LLDP [802.1AB] is explicitly specified to be usable with "Any group
MAC address" and "Any individual MAC address" as the destination
address. That standard also documents specific destination MAC
addresses with different scope for propagation across various bridge
types specified by IEEE 802.1 such as:
o Nearest Customer Bridge: Propagation stops at the nearest Customer
Bridge; i.e. such frames would pass through Provider Bridges and
Two-port MAC Relays (TPMRs) [802.1Q]. (01-80-C2-00-00-00)
o Nearest Non-TPMR Bridge: Propagation stops at the nearest Customer
or Provider Bridge, but not at a TPMR. (01-80-C2-00-00-03)
o Nearest Bridge: Propagation stops at the nearest bridge of any
type, including a TPMR. (01-80-C2-00-00-02)
Note that the devices that stop the propagation of LLDP frames are
the only devices that process them; other devices forward them as if
they were regular data frames.
A new Nearest-RBridge multicast MAC address (see Section 4) is used
as a destination MAC address with LLDPUs to send them to neighbor
RBridges. There may in the future be other uses of the Nearest-
RBridge multicast MAC address; in such applications, the Ethertype of
those frames would be different than the LLDP EtherType (0x88CC).
2.1 Use on Ethernet Ports
LLDPDUs sent with the Nearest-RBridge multicast address out an
RBridge Ethernet port are not encapsulated with a TRILL Header and
are sent natively. Intervening bridges, if any, will be transparent
to frames using this multicast address.
LLDPDUs using the Nearest-RBridge MAC destination address may be
transmitted as permitted by [802.1AB] by an RBridge on any of its
Ethernet ports regardless of the state of any adjacencies [IS-IS]
[RFC6327] on that port.
LLDPDUs may also be sent by an RBridge on Ethernet ports with the
IEEE 802.1 provided destination MAC addresses listed above or other
appropriate destination MAC addresses if other scopes are desired.
D. Eastlake [Page 4]
INTERNET-DRAFT LLDP Support in TRILL
2.2 Use on Other RBridge Ports
If an RBridge port is a port on which an LLDPDU cannot be transmitted
in native form, for example, a PPP TRILL port [RFC6361], the Nearest-
RBridge destination MAC multicast address is still used but the
LLDPDU appears inside a TRILL Data frame as specified in Section 3.
The payload EtherType is the LLDP EtherType (0x88CC) with the
subsequent portion of the frame following normal LLDP rules. This
technique can be used to send an LLDPDU out any non-Ethernet RBridge
port to RBridges that are one hop away.
To assure than any required link initialization has occurred, TRILL
Data frames containing LLDPDUs MUST NOT be transmitted out an RBridge
port unless there is at least one adjacency [IS-IS] [RFC6327] on that
port in a state other than Down. The rate of transmission of such
frames is governed by the same rules as native LLDPDUs [802.1AB].
An LLDPDU received in a TRILL Data frame must pass the tests in
Section 3.2 before being passed on to LLDP to be acted on.
D. Eastlake [Page 5]
INTERNET-DRAFT LLDP Support in TRILL
3. Nearest-RBridge as Inner.MacDA
The Nearest-RBridge multicast MAC address is not intended to be
forwarded by an Rbridge, and as a result the scope of a frame with
this address as the MAC destination address would be all immediately
adjacent RBridge neighbors on a link. The following sub-sections
specify TRILL Data frame transmission and receipt where the
Inner.MacDA is Nearest-RBridge.
3.1 Transmission
When the Inner.MacDA of a TRILL Data frame is the Nearest-RBridge
multicast MAC, then the following apply. Different uses of this MAC
address are distinguished by the payload EtherType, for example
0x88CC for LLDP.
1. The originating RBridge MUST set the Inner.MacSA to a MAC address
unique within the campus owned by that originating RBridge. This
MAY be the same Inner.MacSA used for ESADI [ESADIdraft] and/or
RBridge Channel [Channel] frames.
2. The Inner.VLAN defaults to 0x001 and is ignored on receipt unless
otherwise specified.
3. TRILL Header fields MUST be set as follows:
3.a the hop count is initialized to the maximum value (0x3F),
3.b the M bit is set to zero,
3.c the ingress nickname is a nickname owned by the originating
RBridge,
3.d the egress nickname is set to Any-RBridge. RBridges supporting
the Nearest-RBridge MAC address MUST recognize the Any-RBridge
egress nickname.
4. The link header/trailer are set as for a multi-destination TRILL
Data frame [RFC6325].
3.2 Receipt
When a TRILL Data frame with an Inner.MacDA of Nearest-RBridge is
egressed at an RBridge, it MUST be discarded unless it passes the
following TRILL Header tests:
D. Eastlake [Page 6]
INTERNET-DRAFT LLDP Support in TRILL
1. The M bit is zero and the egress nickname is Any-RBridge.
2. The hop count confirms that it came from an immediate neighbor
[RFC5082]; that is, the hop count is 0x3F before decrement or 0x3E
if tested after decrement.
If not discarded, it is assumed to be directed to the egress RBridge
itself and is handled as appropriate for the payload protocol.
D. Eastlake [Page 7]
INTERNET-DRAFT LLDP Support in TRILL
4. Change in RFC 6325
A change in the behavior mandated by [RFC6325] is required to support
the optional features specified in this document, as follows:
An RBridge conformant to [RFC6325] will discard an Ethernet frame
that it receives whose Outer MAC destination address is the
Nearest-RBridge multicast address. To support LLDP to that address
as described in Section 2.1 above, an RBridge must accept such
frames and process them appropriately depending on their protocol
type if the RBridge implements that protocol. For example, if the
EtherType is the LLDP EtherType and LLDP is implemented at the
receiving RBridge, it would be processed as an LLDPDU.
5. IANA Considerations
IANA is requested to allocate a new TRILL multicast address
[01-80-C2-00-00-44 suggested] for use as the Nearest-RBridge address
and add this to the TRILL Multicast Addresses sub-registry.
6. Security Considerations
This document specifies how to send LLDPDUs between adjacent
RBridges. These techniques increase the span of the "link" over which
LLDP can operate. This increased span may require use of additional
security measures depending on the uses to which LLDP is put. If
sensitive information is being transported, then appropriate link
security should be used, depending on the link type, such as IEEE
[802.1AE] for Ethernet links.
Should an RBridge that does not understand the Any-RBridge egress
nickname accept a frame with Outer.MacDA of All-RBridges but with the
M bit zero in the TRILL Header it will simply discard the frame as
having a reserved egress nickname value.
D. Eastlake [Page 8]
INTERNET-DRAFT LLDP Support in TRILL
Normative References
[802.1AB] - IEEE 802.1, "IEEE Standard for Local and metropolitan
area networks / Station and Media Access Control Connectivity
Discovery", IEEE Std 802.1AB-2009, 17 September 2009.
[IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to
Intermediate System Intra-Domain Routing Exchange Protocol for
use in Conjunction with the Protocol for Providing the
Connectionless-mode Network Service (ISO 8473)", 2002.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5082] - Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC
5082,
[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, A. Ghanwani,
"Routing Bridges (RBridges): Base Protocol Specification", RFC
6325, July 2011.
[RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D.,
and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC
6327, July 2011.
[ESADIdraft] - H. Zhai, F. Hu, R. Perlman, D. Eastlake, draft-ietf-
trill-esadi, work in progress.
Informative References
[802] - IEEE 802, "IEEE Standard for Local and metropolitan area
networks: Overview and Architecture", IEEE Std 802-2001, 8
March 2002.
[802.1AE] - IEEE 802.1, "IEEE Standard for Local and metropolitan
area networks / Media Access Control (MAC) Security", IEEE Std
802.1AE-2006, 18 August 2006.
[802.1Q] - IEEE 802.1, "IEEE Standard for Local and metropolitan area
networks / Virtual Bridged Local Area Networks", IEEE Std
802.1Q-2011, 31 August 2011.
[RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC 6361, August 2011.
[Channel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward,
D. Eastlake [Page 9]
INTERNET-DRAFT LLDP Support in TRILL
draft-ietf-trill-rbridge-channel, work in progress.
D. Eastlake [Page 10]
INTERNET-DRAFT LLDP Support in TRILL
Authors' Addresses
Donald Eastlake 3rd
Huawei R&D USA
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Anoop Ghanwani
Dell
350 Holger Way
San Jose, CA 95134 USA
Phone: +1-408-571-3500
Email: anoop@alumni.duke.edu
D. Eastlake [Page 11]
INTERNET-DRAFT LLDP Support in TRILL
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
D. Eastlake [Page 12]
