One document matched: draft-eastlake-trill-vendor-channel-00.txt
TRILL Working Group Donald Eastlake
INTERNET-DRAFT Yizhou Li
Intended status: Proposed Standard Weiguo Hao
Huawei
Ayan Banerjee
Insieme
Expires: August 15, 2013 February 16, 2013
TRILL: Vendor Specific TRILL Channel Protocol
<draft-eastlake-trill-vendor-channel-00.txt>
Abstract
The IETF TRILL (TRansparent Interconnection of Lots of Links)
protocol is implemented by devices called TRILL switches or RBridges
(Routing Bridges). TRILL includes a general mechanism, called RBridge
Channel, for the transmission of typed messages between RBridges in
the same campus and between RBridges and end stations on the same
link. This document specifies how to send vendor specific messages
over the RBridge Channel facility.
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 TRILL working group mailing list.
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, et al [Page 1]
INTERNET-DRAFT TRILL: Vendor Channel
Table of Contents
1. Introduction............................................3
1.1 Terminology and Acronyms...............................3
2. Vendor Channel Packet Format............................4
3. Vendor Channel Errors...................................6
3.1 Sending an Error Response..............................6
4. IANA Considerations.....................................8
5. Security Considerations.................................9
Normative References......................................10
Informative References....................................10
Acknowledgements..........................................10
Authors' Addresses........................................11
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL: Vendor Channel
1. Introduction
The IETF TRILL (TRansparent Interconnection of Lots of Links)
protocol [RFC6325] is implemented by devices called TRILL switches or
RBridges. It provides efficient least cost transparent frame routing
in multi-hop networks with arbitrary topologies and link
technologies, using link-state routing and a hop count. Links between
TRILL switches can be arbitrary technology and, in general, the TRILL
way to address or specify a TRILL switch (RBridge) in the interior of
a TRILL campus is by its TRILL provided nickname [RFC6325]
[ClearCorrect].
The TRILL protocol includes an RBridge Channel facility [RFCchannel]
to support typed message transmission between RBridges in the same
campus and between RBridges and end stations on the same link. This
document specifies a method of sending messages specific to a
particular organization, indicated by OUI (Organizationally Unique
Identifier [RFC5342]), over the RBridge Channel facility.
Such organization specific messages can be used for vendor specific
diagnotic or experimental messages.
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].
This document uses the acronyms defined in [RFC6325] supplemented by
the following additional acronym:
OUI - Organizationally Unique Identifier [RFC5342]
TRILL switch - An alternative term for an RBridge
D. Eastlake, et al [Page 3]
INTERNET-DRAFT TRILL: Vendor Channel
2. Vendor Channel Packet Format
The general structure of an RBridge Channel packet on a link between
RBridges (TRILL switches) is shown in Figure 1 below. When an RBridge
Channel message is sent between an RBridge and an end station on the
same link, in either direction, the TRILL Header is omitted. The type
of RBridge Channel packet is given by a Protocol field in the RBridge
Channel Header which indicates how to interpret the Channel Protocol
Specific Payload. See [RFCchannel].
Frame Structure
+-----------------------------------+
| Link Header |
+-----------------------------------+
| TRILL Header |
+--------------------------------+ |
| Inner Ethernet Addresses | |
+--------------------------------+ |
| Data Label (VLAN or FGL) | |
+--------------------------------+--+
| RBridge Channel Header |
+-----------------------------------+
| Channel Protocol Specific Payload |
+-----------------------------------+
| Link Trailer (FCS if Ethernet) |
+-----------------------------------+
Figure 1. RBridge Channel Packet Structure
Figure 2 below expands the RBridge Channel Header and Channel
Protocol Specific Payload above for the case of the Vendor Specific
RBridge Channel Tunnel Protocol.
D. Eastlake, et al [Page 4]
INTERNET-DRAFT TRILL: Vendor Channel
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
RBridge Channel Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RBridge-Channel (0x8946) | 0x0 | Channel Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | ERR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor RBridge Channel Protocol Specific:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI (cont.) | VERR | Sub-Protocol | Sub-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Protocol Specific Data
|
| ...
Figure 2. Channel Tunnel Message Structure
The fields in Figure 2 related to the Vendor RBridge Channel Protocol
are as follows:
Channel Protocol: The RBridge Channel Protocol value allocated
for Vendor Channel (see Section 4).
OUI: The field indicates the vendor specifying the particular use
or uses of the Vendor Channel. The vendor to whom the OUI in
this field has been allocated is in charge of specifying Vendor
Channel messages using their OUI.
VERR: Vendor Channel Error. See Section 3.
Sub-Protocol: Actually, the vendor specifying their use of the
Vendor Channel can do whatever they want with the bits after
the VERR field. But it is strongly recommended that they use
the sub-protocol / sub-version fields so that multiple and
evolving uses can be specified based on a single OUI.
Sub-Version: See explanation above of the Sub-Protocol field. This
field is provided to indicate the version of the particuar
vendor's Sub-Protocol.
D. Eastlake, et al [Page 5]
INTERNET-DRAFT TRILL: Vendor Channel
3. Vendor Channel Errors
The VERR field values from 0x0 through 0xF inclusive are reserved for
specification by the IETF. See Section 4. All other non-zero values
of VERR are available for whatever use the vendor specifies except
that a Vendor Channel implementation MUST NOT send a Vendor Channel
Error in response to a Vendor Channel message with a non-zero VERR
field.
The IETF specified VERR values thus far are as follows:
0. The VERR field is zero in Vendor Channel messages unless the the
Vendor Channel packet is reporting an error.
1. The value one indicate that the OUI field value is unknown. If an
RBridge implements the Vendor Channel facility and receives a
Vendor Channel packet with a zero VERR field and an OUI field it
does not recognize and the SL flag is zero in the RBridge Channel
Header, it MUST set the VERR field to the value one and returns
the packet as described in Section 3.1.
2. The value two indicates that the Sub-Protocol field value is
unknown. If an RBridge implements the Vendor Channel facility and
receives a Vendor Channel packet with a zero VERR field and zero
SL flag in the RBridge Channel Header, an OUI that it implements,
but a Sub-Protocol fields value it does not recongize, it SHOULD
set the VERR field to the value two and returns the packet as
described in Section 3.1.
3. The value three indicates that the Sub-Version field value is
unknown. If an RBridge implements the Vendor RBridge Channel
facility and receives a Vendor Channel packet with a zero VERR
field and zero SL flag in the RBridge Channel Header, an OUI and
Sub-Protocol that it implements, but a Sub-Version fields value it
does not recongize, it SHOULD set the VERR field to the value
three and returns the packet as described in Section 3.1.
3.1 Sending an Error Response
The IETF specified Vendor Channel error response are sent in response
to a received RBridge Channel packet by setting the VERR field as
specified above and modifying the packet as specified below.
The RBridge Channel Header is modified by setting the SL flag.
(The ERR field will be zero because, if it was non-zero, the
packet would have been handled at the RBridge Channel rather than
being passed down to the Vendor Channel level.)
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL: Vendor Channel
o If Vendor Channel message was sent between RBridges, the TRILL
Header is modified by clearing the M bit, setting the egress
nickname to the ingress nickname as received, and setting the
ingress nickname to a nickname held by the TRILL switch sending
the error packet.
o If Vendor Channel message was sent between an RBridge and an end
station in either direction, the outer MAC addresses are
modified by setting the Outer.MacDA to the Outer.MacSA as
received, and the Outer.MacSA is set to the MAC address of the
port of the TRILL switch or end station sending the error
packet.
o The priority of the error response message MAY be reduced from
the priority of the Vendor Chanel messge causing the error,
unless it was already minimum priority, and MAY set the Drop
Eligibility Indicator bit in an error response. (Priorities are
ordered from highest to lowest as 7, 6, 5, 4, 3, 2, 0, and 1.
See Section 4.1.1, [RFC6325].)
It is generally anticipated that the entire packet in which an error
was detected would be sent back, modified as above, so that, for
example, error responses could more easily be matched with messages
sent; however, this is really up to the vendor specifying how their
Vendor RBridge Channel messages are to be used.
D. Eastlake, et al [Page 7]
INTERNET-DRAFT TRILL: Vendor Channel
4. IANA Considerations
IANA is requested to allocate TBD for Vendor Specific RBridge Channel
Protocol from the range of RBridge Channel protocols allocated by
Standards Action.
IANA is requested to establish a "Vendor RBridge Channel Error Codes"
registry with initial entries as follows:
Code Description Reference
---- ----------- ---------
0 No error This document
1 Unknown OUI This document
2 Unknown Sub-Protocol This document
3 Unknown Sub-Version This document
0x04-0x0F Allocated by Standards Action -
0x10-0xFF Reserved for vendor use This document
D. Eastlake, et al [Page 8]
INTERNET-DRAFT TRILL: Vendor Channel
5. Security Considerations
See [RFC6325] for general TRILL Secuirty Considerations.
See [RFCchannel] for general RBridge Channel Security Considerations.
The Vendor Specific RBridge Channel Protocol provides no security
assurances or features. Any needed security could be provided by
fields or processing within the Vendor Protocol Specific Data, which
is outside the scope of this document. Alternatively, use of Vendor
Channel could be nested inside the RBridge Channel Tunnel Protocol
[RFCtunnel] which can provide some security services.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT TRILL: Vendor Channel
Normative References
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5342] - Eastlake 3rd, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September
2008.
[RFC6325] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", RFC 6325,
July 2011.
[RFCchannel] - D. Eastlake, V. Manral, L. Yizhou, S. Aldrin, D. Ward,
"TRILL: RBridge Channel Support", draft-ietf-trill-rbridge-
channel-08.txt, in RFC Edtior's queue.
[ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, A.
Banerjee, "TRILL: Clarifications, Corrections, and Updates",
draft-ietf-trill-clear-correct, work in progress.
Informative References
[RFCtunnel] - Eastlake, D., ... "TRILL: Channel Tunnel", draft-
eastlake-trill-channel-tunnel, work in progress.
Acknowledgements
The document was prepared in raw nroff. All macros used were defined
within the source file.
D. Eastlake, et al [Page 10]
INTERNET-DRAFT TRILL: Vendor Channel
Authors' Addresses
Donald E. Eastlake, 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56622310
Email: liyizhou@huawei.com
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012, China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Ayan Banerjee
Insieme Networks
210 West Tasman Drive
San Jose, CA 95134 USA
Email: ayabaner@gmail.com
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL: Vendor Channel
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2013 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, et al [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-23 16:14:23 |