IS-IS Point-to-Multipoint operation
NetDEF
Leipzig
DE
chris@opensourcerouting.org
NetDEF
04229
Leipzig
Germany
david@opensourcerouting.org
Deutsche Telekom
chopps@chopps.org
Routing
Network Working Group
IS-IS Multipoint Multicast
This document describes a new mode operation for IS-IS. In addition
to the existing LAN and point-to-point modes of operation, a point-to-multipoint
mode is defined. This mode is useful for operation both on networks with more than
two routers where multicast is expensive in comparison to unicast, as well on
networks where creating a LAN pseudonode cannot adequately
reflect metrics.
The core functionality of the protocol outlined in this document
consists of an additional Subnetwork dependent function per Section 8 of ISO/IEC 10589:2002.
In that regard, the next section can be understood as new section "8.5
Point-to-multipoint networks".
The outlined protocol is remotely similar to the derelict section
"8.3 ISO 8208 subnetworks" in that multiple
point-to-point adjacencies are established on an interface.
Point-to-multipoint operation of IS-IS is thus not a new idea; in
fact section 6.2 already mentions "multipoint links." This document
re-enables the concept.
In place of ISO 8473 call management
establishing sessions, this document establishes pairwise
"pseudocircuits" between two IS on a common medium. Multiple such
pseudocircuits can normally exist on one P2MP (Point-To-Multipoint) interface.
Each pseudocircuit operates, aside from subnetwork attachment
procedures, exactly as a P2P (Point-to-Point) link.
It should be noted that while the Multicast autodiscovery
mechanism requires broadcast capability, no other part of the
protocol does. The P2MP interface type can be used on
non-transitive and/or non-broadcast interfaces.
An implementation maintains a set of pseudocircuits per P2MP
interface. Each pseudocircuit is uniquely identified by the local
interface and peer's SNPA address.
Each participating system MUST use a consistent SNPA address per
local interface. A change in SNPA address results in all neighbors
treating the interface as distinct from the previous one. A system
MAY support multiple SNPA addresses per interface by treating them as
distinct interfaces.
Unnumbered media are not supported by this protocol. Each
participant on a link MUST have an unique SNPA address on that
link.
Pseudocircuits are represented in LSPs as a regular P2P circuit
would be. As a result, their treatment in SPF calculations is also
identical to P2P circuits.
In scenarios where pseudocircuits do not form a full mesh of all
participants on a medium, the best path for a packet may be
through the same interface as the one it was received on.
Systems implementing this specification MUST therefore support
forwarding packets on the same interface that they were received
on. This applies only to interfaces configured for P2MP
operation.
The discovery machinery produces as output a "candidate
neighbor list," which is a list of possible neighbor's SNPAs
and is maintained per P2MP interface. Adding and removing
entries to the candidate neighbor list results in
pseudocircuit creation and deletion.
A neighbors presence on the candidate list may be supported
by multiple sources. These sources are described in the
following sections
The IS-IS implementation SHOULD provide user configuration
to disable or filter individual sources.
A list of neighbor IS MAY be configured by the user, providing
possible neighbor's SNPAs on an interface.
Lower protocol layers (VPLS, IEEE 802.11) may be able to provide
a list of attached neighbors. This list MAY be fed into the
candidate neighbor list.
For broadcast capable networks, this document defines an
autodiscovery mechanism based on multicasting Hello packets. This
mechanism MAY be disabled by the user, but MUST be implemented for
all lower layer link types with (limited or full) broadcast
capability.
A multicast autodiscovery packet is defined as a P2P IIH
which is multicast over the LAN media as defined in . Additionally it must include a Three-Way
Adjacency TLV as defined in
indicating the circuit is in the DOWN state (i.e., 1 octet
of value indicating the DOWN state). Receiving such a Hello
places the sending IS on the candidate list for as long as
the PDU's holdtime indicates.
A system MAY implement a receive-only passive multicast
autodiscovery mode where it adds candidates (forms pseudocircuits)
on receiving autodiscovery PDU, but does not send such PDUs
itself.
If either passive or full multicast autodiscovery is enabled,
receiving a unicast autodiscovery PDU also adds the neighbor to
the candidate list.
Since there may be no underlying protocol layer
partitioning the link into actual P2P circuits in this case, additional handling
is required on bringing up the individual pseudocircuit
adjacencies.
To prevent different pseudocircuits from "bleeding" into each other,
implementations of this protocol MUST enable
on all P2MP pseudocircuits, with changes as follows:
Received IIH PDUs on P2MP pseudocircuits without the
Point-to-Point Three-Way Adjacency option MUST be discarded.
Pseudocircuits are destroyed when their P2P state machine has
transitioned into "Down" state and they are no longer supported as
a candidate by any discovery mechanism.
As long as a pseudocircuit is present, its P2P state machine
will, as expected for P2P circuits, trigger transmission of further
Hello PDUs, even when it is in Down state.
Acknowledge Les Ginsberg for pointing out that P2P Hellos
rather than LAN hellos could and should be used.
(no changes/keepalive)
Moved from new P2MP Hello PDU to
using existing P2P PDU.
Initial Version
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)
ISO/IEC
X.25 Packet Layer Protocol for Data Terminal Equipment
ISO/IEC
Protocol for providing the connectionless-mode network
service: Protocol specification
ISO/IEC