Network Working Group L. Yong
Internet Draft W. Hao
D. Eastlake
Category: Standard Track Huawei
Expires: January 2014 July 8, 2013
ISIS Protocol Extension For Building Distribution Trees
draft-yong-isis-ext-4-distribution-tree-00
Abstract
This document proposes an IS-IS protocol extension for automatically
building bi-directional distribution trees to transport multi-
destination traffic in an IP network.
Status of this document
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and 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 January 8, 2014.
Yong, et al [Page 1]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
Copyright Notice
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.
Table of Contents
1. Introduction...................................................3
1.1. Conventions used in this document.........................4
2. IS-IS Protocol Extension.......................................4
2.1. RTADDR sub-TLV............................................4
2.2. RTADDRV6 sub-TLV..........................................6
2.3. The Group Address Sub-TLV.................................7
3. Procedures.....................................................8
3.1. Distribution Tree Computation.............................8
3.2. Parent Selection..........................................8
3.3. Parallel Local Link Selection.............................9
3.4. Tree Selection for a Group...............................10
3.5. Pruning a Distribution Tree for a Group..................10
3.6. RPF Mechanism............................................10
3.7. Forwarding Using a Pruned Distribution Tree..............10
3.8. Local Forwarding at Edge Router..........................11
3.9. Distribution Tree across different IGP Levels............12
4. Backward Compatibility........................................12
5. Security Considerations.......................................12
6. IANA Considerations...........................................12
7. Acknowledgements..............................................12
8. References....................................................12
8.1. Normative References.....................................12
8.2. Informative References...................................13
Yong, et al. [Page 2]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
1. Introduction
The computer virtualization and cloud applications motivate the DC
network virtualization technology [NVO3FRWK]. This technology
decouples the end-points networking from the DC physical
infrastructure network in terms of address space and configuration
[NVO3FRWK].
DC network virtualization solutions are necessary to carry all types
of traffic in today's DC physical networks including multi-
destination traffic. It is also desirable to use IP network as the
DC underlying network for the overlay virtual networks [NVO3FRWK].
IP network technology does not yet support multi-destination traffic
forwarding. A variant of Protocol Independent Multicast (PIM)
solutions [RFC4601] [RFC5015] are designed to carry IP multicast
traffic over IP networks. However the PIM solutions use their own
hello protocol and hop-to-hop Join/Leave message so each router does
not have global information about the receivers; in the PIM
solution, the data packets could be forwarded unnecessarily to the
Rendezvous Point(RP), and then get dropped there when no receiver at
all or the sender and receivers for a multicast group are on the
same branch towards the RP, which consumes network resources.
Furthermore PIM solutions maintain a lot of soft-state, have
intensive CPU utilization, and have additional convergence time
besides IGP's under a failure condition.
Although the PIM protocol is mature and has been deployed in IP
networks, applying PIM to the IP network that supports the Network
Virtualization can be an extreme challenge [MCASTISS]. For example,
VXLAN [VXLAN] solutions requires multicast support in the underlying
network to simulate overlay L2 broadcast capability, where every
edge node in an overlay virtual network (VN) is a multicast source
and receiver. An overlay VN topology may be sparse and dynamic
compared to the underlying IP network topology. Also large number of
overlay VNs may exist in a DC, which PIM solutions can't scale to.
This document uses extensions to the IS-IS protocol to build a
distribution tree for multi-destination traffic transport in an IP
network. A router uses Router Capability message to announce the
tree root address and the multicast groups associated to the tree.
With this information, routers in the IGP can compute rooted
distribution trees by using the link state information, i.e. LSDB,
and shortest path algorithm. Edge routers include information in
their LSPs to announce their multicast group-memberships. Routers
perform distribution tree pruning for each multicast group based on
Yong, et al. [Page 3]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
router's group membership announcement. A router forwards the multi-
destination traffic along the pruned tree.
In this solution, edge routers use IGMP query messages to inform the
attached hosts and the hosts use IGMP report message to response
with their interested multicast group(s). The edge routers announce
interested multicast groups in their LSPs so they are flooded to
whole network.
The benefits of this solution are 1) protocol convergence: use
single protocol for both unicast and multicast traffic transport and
get the same convergence time for unicast and multicast traffic. 2)
multi-destination transport simplification: rely on the LSDB for
computing a distribution tree and not run PIM hello protocol. 3)
forwarding efficiency: no need to always forward the traffic to the
RP; 4) better scalability: no need to maintain heavy PIM soft
states. TRILL [RFC6325] has used IS-IS protocol for both single
destination and multi-destination packet transport, which proves the
protocol capability for doing both.
1.1. Conventions used in this document
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 RFC-2119 [RFC2119].
2. IS-IS Protocol Extension
2.1. RTADDR sub-TLV
This is the sub-TLV of Router Capability TLV. Each RTADDR sub-TLV
contains a root IPv4 address and multicast group addresses that
associate to the tree. A router may use multiple RTADDR sub-TLVs to
announce multiple root addresses and associated multicast groups
with each root. RTADDR sub-TLV format is below.
Yong, et al. [Page 4]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
+-+-+-+-+-+-+-+-+
|Type=RTADDR | (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology ID | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Priority | (1 byte)
+-+-+-+-+-+-+-+-+
|Num of Groups | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Mask (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GROUP Address (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Mask (N) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Type: sub-TLV of Router Capability for RTADDR (TBD)
Length: variable depending on the number of associated groups
Topology ID: This field carries a topology ID [RFC5120] or zero if
topologies are not in use.
Root IP Address: IPv4 Address for a root
Tree Priority: high number means higher priority. Zero means no
priority.
Num of Groups: the number of group addresses
Group Address: IPv4 Address for the group
Group Mask: multicast group range
Yong, et al. [Page 5]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
One router may be the root for multiple trees, each tree associates
to a set of multicast groups. In this case, a router encodes
multiple RTADDR sub-TLVs to announce root addresses, one for each
root, in a router capability TLV. The group address/mask in
different sub-TLVs can overlap. See section 3 for detail.
2.2. RTADDRV6 sub-TLV
This sub-TLV is used in IPv6 network. It has the same format and
usage except that the addresses are in IPv6.
Yong, et al. [Page 6]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
+-+-+-+-+-+-+-+-+
|Type = RTADDRV6| (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Root IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RESV | Topology ID | (2 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tree Priority | (1 byte)
+-+-+-+-+-+-+-+-+
|Num of Groups | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Group IPv6 Address (1) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MASK(1) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.3. The Group Address Sub-TLV
The Group Address TLV and a set of Group Address sub-TLVs are
defined in RFC6326-bis [RFC6326BIS]. The GIP-ADDR and GIPV6-ADDR
sub-TLVs are used in this solution. An edge router uses the GIP-ADDR
sub-TLV or GIPV6-ADDR to announce its interested multicast groups.
Yong, et al. [Page 7]
Internet-Draft ISIS Ext. For Distribution Tree July 2013
The GIP-ADDR sub-TLV applies to an IPv4 network and GIPV6-ADDR sub-
TLV for IPv6 network.
When using a GIP-ADDR or GIPV6-ADDR sub-TLV, the field VLAN-ID MUST
set to zero and be ignored. Other field usage remains the same as
[RFC6326-BIS]
3. Procedures
When an operator selects a router as a distribution tree root,
he/she configures the tree root address and associated multicast
groups on the router. A tree root address can be an interface
address or router loopback address. After the configuration, the
router will include a RTADDR sub-TLV, inside a router capability TLV,
where the tree root address and multicast groups are specified. If
multiple trees are configured on the router, multiple RTADDR sub-
TLVs are added in one router capability TLV to specify individual
tree roots. For IPv4 network, RTADDR sub-TLV is used. For IPv6,
RTADDRV6 sub-TLV is used. Note that the rest of document specifies
the processes for an IPv4 network only and the processes for an IPv6
network is the same.
Operator may associate one multicast group to more than one tree for
the redundancy purpose and use the tree priority to specify the
primary tree preference.