One document matched: draft-ward-l2isis-02.txt
Differences from draft-ward-l2isis-01.txt
Network Working Group D. Ward
Internet-Draft Cisco Systems
Expires: December 15, 2007 R. Perlman
Sun Microsystems
R. White
D. Farinacci
A. Banerjee
Cisco Systems
June 13, 2007
Carrying Attached Addresses in IS-IS
draft-ward-l2isis-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 15, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This draft specifies the IS-IS extensions necessary to support multi-
link IPv4 and IPv6 networks, as well as to provide true link state
routing to any protocols running directly over layer 2. While
Ward, et al. Expires December 15, 2007 [Page 1]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
supporting this concept involves several pieces, this document only
describes extensions to IS-IS. We leave it to the systems using
these IS-IS extensions to explain how the information carried in
IS-IS is used.
1. Overview
There are a number of systems which have proposed using layer 2
addresses carried in a link state routing protocol, specifically
IS-IS [IS-IS] [RFC1195], to provide true layer 2 routing in specific
environments. This draft proposes a set of TLVs added to [IS-IS]
level 1 PDUs, and a new PDU type, to support these proposed systems.
This draft does not propose new forwarding mechanisms using this
additional information carried within IS-IS. There is a short
section included on two possible ways to build a shortest path first
tree including this information, to illustrate how this information
might be used.
2. Proposed Enhancements to IS-IS
This draft proposes additional TLVs to carry identity and prioity
information, as well as attached address information. This draft
also proposes a new IS-IS PDU, the Multicast Group (MGROUP) PDU, for
carrying a list of attached or joined multicast groups.
2.1. The ADDR TLV
The ADDR TLV is IS-IS TLV type [TBD], and has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+---------------+---------------+-------------------------------+
| Address Sub-TLVs....
+----
o Type: TLV Type, set to [TBD].
o Length: Total number of octets contained in the TLV, including the
length of each Sub-TLV within the ADDR TLV.
o Reserved: Set to 0.
The ADDR TLV MUST be carried in a level-1 pseudo-node LSP generated
by the originating IS.
An ADDR TLV may carry two types of sub-TLVs, addresses and
Ward, et al. Expires December 15, 2007 [Page 2]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
attributes. This document defines two address sub-TLVs, and a single
attribute sub-TLV. All attribute sub-TLVs carried within a single
ADDR TLV apply to all of the address TLVs carried within the same
ADDR TLV.
If an ADDR TLV is carried within a standard Level 1 link state PDU,
it SHOULD contain only unicast addresses. If an ADDR TLV is carried
in an MGROUP PDU, described later in this document, it SHOULD contain
only multicast group addresses.
2.1.1. The Single AFI Type
A Single AFI TLV is used to carry a list of addresses of a single AFI
for devices attached to, or reachable from, the IS. Zero or more of
these sub-TLVs MAY be carried in the ADDR TLV.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | AFI Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....
+----------------
o Type: Set to 1.
o Length: Set to the total length of the sub-TLV in octets.
o AFI Type: The IANA defined AFI type of the included addresses
[IANA].
o Addresses: One or more addresses of the type specified in the AFI
Type field.
2.1.2. The Address Pair Type
The Address Pair Sub-TLV carries a pair of related addresses, with
each address type defined using an IANA assigned AFI type. The first
address of the pair is the "reachable through" address, and the
second is the destination address. Zero or more Address Pair Type
sub-TLVs MAY be included in a single ADDR TLV.
Ward, et al. Expires December 15, 2007 [Page 3]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IS AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IS Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AN AFI | AN Address (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ....
+-------------
o Type: Set to 2.
o Length: Set to the total number of octets in the sub-TLV.
o IS AFI: The IANA defined AFI type of address contained in the RT
Address [IANA].
o IS Address: The reachable through, or IS, address.
o AN AFI: The IANA defined AFI type of address contained in the AN
Address [IANA].
o AN Address: The attached node, or reachable, address.
This sub-TLV may be used in several ways, including (but not limited
to):
o The first address may be an IS address, with the second address
being an attached node.
o The first address may be an attached node layer 2 address, with
the second address being the same attached node's layer 3 address.
2.1.3. The VLAN Type
The VLAN sub-TLV carries a 32 bit VLAN identifier. Any address
within (or a part of) a VLAN SHOULD be carried in an ADDR TLV
containing a VLAN sub-TLV indicating the VLAN to which it belongs.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN ID |
+---------------------------------------------------------------+
o Type: Set to 3.
o Length: Set to 4.
o Options: Optional Flags (see below).
o VLAN ID: Set to the VLAN identifier. All address sub-TLVs carried
within the same ADDR TLV are considered part of the VLAN
identified in this field.
Ward, et al. Expires December 15, 2007 [Page 4]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
The Options field is treated as 16 flags indicating additional
information about this VLAN or the status of the advertising IS on
this VLAN:
o Bit 0: If set, indicates this IS has directly connected end nodes
(or end nodes learned through some other mechanism than through
IS-IS).
o Bits 1-15: Reserved
2.2. The Device ID TLV
The Device ID (DEVID) TLV carries information about the identity of
the advertising device, along with information about device priority.
The Device-Id TLV MUST be carried in a level-1 pseudo-node LSP
generated by the originating IS.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Device Id |
+---------------------------------------------------------------+
o Type: TLV Type, set to [TBD].
o Length: Total number of octets contained in the TLV, including the
length of each Sub-TLV within the DEVID TLV.
o Options: Set ot 0.
o Device ID: Left padded device ID or alias.
2.3. The Root Priority TLV
The Root Priority TLV MUST be carried in a level-1 pseudo-node LSP
generated by the originating IS. Each switch announces a broadcast
root-priority and a multicast root-priority. Once a node receives a
new LSP, it runs an election algorithm, independently of the other
nodes in the network, to determine the broadcast root. The node that
announced the lowest broadcast priority becomes the root of the
broadcast tree. If two devices advertise the same broadcast
priority, the device with the lower system ID becomes the root of the
boradcast treee. The elected broadcast-root will decide on the
multicast-roots based on the multicast priorities advertised. The
elected broadcast-root then decides on the number of multicast trees
to be computed and their roots. This announcement takes place in the
multicast root sub-TLV.
Ward, et al. Expires December 15, 2007 [Page 5]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Br. Root Pri | Mu. Root Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to [TBD].
o Length: Total number of octets contained in the TLV, including the
length of each Sub-TLV within the DEVID TLV.
o Options: TBD.
o Reserved: Set to 0.
o Device Id: The Device-Id used in forwarding frames.
2.3.1. The Multicast Root Identifier Sub-tlv
The Multicast root identifier sub-tlv is populated by the root of the
broadcast tree and is given as:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Multicast Root Device Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Root Device Id | ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: TLV Type, set to 1.
o Length: Total number of octets contained in the TLV.
o Multicast Root Device Id: The Multicast Root Device ID at which a
multicast tree is rooted.
A locally significant hash is used by edge devices to determine which
multicast root (or set of multicast roots) is used to send traffic
for a specific multicast group.
2.4. The Multicast Group PDU
The Multicast Group (MGROUP) PDU can be used to advertise a set of
attached, or joined, multicast groups. The MGROUP PDU is formatted
identical to a Level 1 Link State PDU, as described in Section 9.3 of
[IS-IS]. One field, PDU Type, is changed to [TBD], to signify this
PDU is carrying multicast group information, rather than unicast
reachability information.
The Multicast Group PDU carries TLVs indicating multicast groups; one
TLV is defined in this document, the MSAGA TLV.
Ward, et al. Expires December 15, 2007 [Page 6]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source |
+---------------------------------------------------------------+
| .... | Destination |
+---------------------------------------------------------------+
| |
+---------------------------------------------------------------+
| (additional source/group pairs) ....
+-------------------------------------+
o Type: Set to 1
o Length: Set to the total length of the TLV.
o Options: Optional Flags (none define).
o Source: A six octet source address for this multicast group. If
the source is set to 0, the TLV describes a (*,G) entry rather
than a (S,G) entry.. This supports IGMPv2 hosts joining (*,G)
groups.
o Destination: A six octet group address for this multicast group.
One or more source/group address pairs MAY be included in this TLV.
One or more MSAGA TLVs MAY be carried in a single MGROUP PDU. Future
multicast address TLVs MAY be defined using type codes other than 1,
and be carried in an MGROUP PDU.
3. Considerations for Using L2 Information in IS-IS
While this document does not specify the way in which addresses
carried in these TLVs is used in IS-IS, two general areas of concern
are considered in this section: building the SPF tree when using this
information, and the election of designated intermediate systems
(DIS) in an environment using this information.
3.1. Building SPF Trees with Layer 2 Information
Each IS which is part of a single broadcast domain from a layer 2
perspective will build a single SPF tree (SPT) for every IS
indicating connected layer 2 end nodes or advertising direct
connections to layer 2 end nodes. An optimal unicast forwarding path
and an optimal flooding path to any given layer 2 address or set of
layer 2 addresses can be developed using these trees.
We assume some mechanism for forwarding traffic to these attached
addresses added to the SPT is provided for in the mechanism proposing
Ward, et al. Expires December 15, 2007 [Page 7]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
the use of these extension TLVs.
3.2. Designated Intermediate Routers
A single DIS SHOULD be elected as described in [IS-IS] for each layer
2 broadcast domain (VLAN) for which information is being carried in
IS-IS. This reduces the amount of work required to flood and
maintain synchronized databases over the underlying media on which
IS-IS is running and providing layer 2 forwarding information for.
4. Acknowledgements
5. Security Considerations
This document adds no additional security risks to IS-IS, nor does it
provide any additional security for IS-IS.
6. IANA Considerations
This document creates a new TLV type within IS-IS, the ADDR TLV.
IANA SHOULD assign a TLV descriptor code (type) to this TLV.
This document creates a new sub-TLV numbering space for ADDR TLVs.
Within this space, this document defines three types. IANA SHOULD
manage the remaining space using the consensus method.
7. References
7.1. Normative References
[IS-IS] Heffernan, A., "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)", 2005.
7.2. Informative References
[RBRIDGES]
Perlman, R. and J. Touch, "RBridges: Transparent Routing",
2005.
Ward, et al. Expires December 15, 2007 [Page 8]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
Authors' Addresses
David Ward
Cisco Systems
Email: wardd@cisco.com
Radia Perlman
Sun Microsystems
Email: Radia.Perlman@Sun.com
Russ White
Cisco Systems
Email: riw@cisco.com
Dino Farinacci
Cisco Systems
Email: dino@cisco.com
Ayan Banerjee
Cisco Systems
Email: ayabaner@cisco.com
Ward, et al. Expires December 15, 2007 [Page 9]
Internet-Draft Carrying Attached Addresses in IS-IS June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ward, et al. Expires December 15, 2007 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 01:54:07 |