One document matched: draft-ginsberg-isis-udl-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ginsberg-isis-udl-00.txt"
ipr="pre5378Trust200902">
<front>
<title abbrev="draft-ginsberg-isis-udl-00.txt">IS-IS Support for
Unidirectional Links</title>
<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<code>95035</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>ginsberg@cisco.com</email>
</address>
</author>
<author fullname="Sina Mirtorabi" initials="S" surname="Mirtorabi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3800 Zankar Road</street>
<city>San Jose</city>
<code>95134</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>smirtora@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<city>Rome</city>
<code>0144</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Abhay Roy" initials="A" surname="Roy">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>560 McCarthy Blvd.</street>
<city>Milpitas</city>
<code>95135</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>akr@cisco.com</email>
</address>
</author>
<date day="15" month="February" year="2013"/>
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword>Sample</keyword>
<abstract>
<t>This document defines support for the operation of IS-IS over
Unidirectional Links without the use of tunnels or encapsulation of
IS-IS Protocol Data Units. Adjacency establishment when the return path
from the router at the receive end of a unidirectional link to the
router at the transmit end of the unidirectional link is via another
unidirectional link is supported. The extensions defined here are
backwards compatible - only the routers directly connected to a
unidirectional link need to be upgraded.</t>
</abstract>
<note title="Requirements Language">
<t>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].</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Operation of IS-IS depends upon two-way connectivity. Adjacencies are
formed by exchanging hellos on a link, flooding of the link state
database is made reliable by exchanges between neighbors on a link, etc.
However, there are deployments where operation of the protocol is
desired over links which are unidirectional i.e., one end of the link
can only send Protocol Data Units (PDUs) and one end of the link can
only receive PDUs. Traditional methods of supporting Unidirectional
Links (UDLs) have involved establishing a tunnel from the Intermediate
System (IS) at the receive end of the UDL to the IS at the transmit end
of the UDL, encapsulating/decapsulating the IS-IS PDUs as they
enter/exit the tunnel, and associating the PDUs received via the tunnel
with the UDL at the transmit end. This typically requires static
configuration and may introduce Maximum Transmission Unit (MTU) issues
due to the required encapsulation.</t>
<t>This specification defines extensions to the protocol which support
correct and reliable operation of IS-IS over UDLs without the need for
tunnels or any form of encapsulation.</t>
</section>
<section title=" Encoding Extensions">
<t>Although the IS at the transmit end of a UDL link (IS-T) can send
IS-IS PDUs normally on the link, the IS at the receive end of a UDL link
(IS-R) requires assistance from other ISs in the network to pass the
information it would normally send directly to IS-T. The Update Process
as defined in [IS-IS] allows information generated by one IS in the
network to be reliably flooded to all other ISs in the network using
Link State PDUs (LSPs). The extensions defined here utilize LSPs to
allow IS-R to send information normally sent in hellos (IIHs) or
sequence number PDUs (SNPs) to IS-T in LSPs. As LSPs are flooded to all
ISs in an area/sub-domain, care is taken to minimize the LSP churn
necessary to support adjacency establishment and maintenance between
IS-T and IS-R.</t>
<section title="UDL LSPs and the UDL-TLV">
<t>Routers on the receive end of a UDL MUST reserve at least one LSP
(for each level supported on the UDL) to advertise the UDL information
described below. Such LSPs are referred to as UDL-LSPs although the
only distinction between a UDL-LSP and other LSPs is in the TLV
information which is present in such an LSP. LSP #0 MUST NOT be used
to send UDL information. UDL-LSPs have the following special
characteristics:</t>
<t><list style="numbers">
<t>The only TLV which may be advertised in UDL-LSPs is the UDL TLV
described below and (optionally) an Authentication TLV and/or
Purge Originator Identification TLV [RFC6232] . This requirement
is enforced by the originator of the UDL-LSP but is not checked by
receiving systems i.e., other TLVs which are included in a UDL-LSP
are processed normally. The reason for the restriction is to
minimize the number of LSPs which have UDL information
content.</t>
<t>Routers on the transmit side of a UDL flood UDL-LSPs regardless
of the existence of an adjacency in the UP state on that circuit.
Flooding of UDL-LSPs on circuits other than a UDL is as specified
in [IS-IS] i.e., no special handling.</t>
</list></t>
<t>A new TLV is defined in which UDL specific information appears. All
information in a UDL-TLV is encoded in sub-TLVs. UDL sub-TLVs are
formatted as specified in [RFC5305]. The format of the UDL-TLV is
therefore:</t>
<figure>
<artwork><![CDATA[ No. of octets
+---------------------------+
| Type (11) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 1
+---------------------------+
| Sub-TLVs | 3 - 255
: :
+---------------------------+
]]></artwork>
</figure>
</section>
<section title="UDL Intermediate System Neighbors sub-TLV">
<t>UDL links may operate in Point-to-Point mode or in broadcast mode
(assuming the subnetwork is a broadcast subnetwork). There are
therefore two types of Intermediate System Neighbors sub-TLVs defined.
A UDL-TLV MUST NOT contain more than one Intermediate System Neighbors
sub-TLV. If multiple Intermediate System Neighbors sub-TLVs appear in
a UDL-TLV all information in that UDL-TLV MUST be ignored.</t>
<section title="UDL Point-to-Point Intermediate System Neighbor Sub-TLV">
<t>The UDL Point-to-Point Intermediate System Neighbor Sub-TLV
describes an adjacency on a UDL which is operating in Point-to-Point
mode i.e. either a Point-to-Point subnetwork or a LAN subnetwork
operating in Point-to-Point mode as described in [RFC5309]. The
information encoded follows the format for the Point-to-Point
Three-Way Adjacency TLV as defined in [RFC5303] but may also include
the local LAN address when the underlying subnetwork is a LAN.</t>
<figure>
<artwork><![CDATA[ No. of octets
+---------------------------+
| Type (240) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (9 + ID Length) | 1
| to (15 + ID Length) |
+---------------------------+
| Adjacency 3-way state | 1
+---------------------------+
| Extended Local Circuit ID | 4
+---------------------------+
| Neighbor System ID | ID Length
+---------------------------+
| Neighbor Extended Local | 4
| Circuit ID |
+---------------------------+
| Local LAN Address | 6
+---------------------------+
]]></artwork>
</figure>
</section>
<section title="UDL LAN Intermediate System Neighbor Sub-TLV">
<t>The UDL LAN Intermediate System Neighbor sub-TLV describes an
adjacency on a UDL operating in broadcast mode on a LAN
subnetwork.</t>
<figure>
<artwork><![CDATA[ No. of octets
+---------------------------+
| Type (6) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (7 + ID Length) | 1
+---------------------------+
| Neighbor LAN ID | ID Length + 1
+---------------------------+
| Local LAN Address | 6
+---------------------------+
]]></artwork>
</figure>
</section>
</section>
<section title="UDL LSP Entry sub-TLV">
<t>The content of this sub-TLV describes LSPs for which the
originating router requires an update. A UDL Intermediate System
Neighbor sub-TLV MUST be included in any UDL-TLV where the UDL LSP
Entry sub-TLV is included. This is necessary so that only the
specified neighbor processes the LSP entries mentioned in the
sub-TLV.</t>
<figure>
<artwork><![CDATA[ No. of octets
+---------------------------+
| Type (9) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length (10 + ID Length)*N | 1
+---------------------------+
: LSP Entries :
+---------------------------+
Each LSP Entry has the following format:
+---------------------------+
| Remaining Lifetime | 2
+---------------------------+
| LSP ID | ID Length + 2
+---------------------------+
| LSP Sequence Number | 4
+---------------------------+
| Checksum | 2
+---------------------------+
]]></artwork>
</figure>
</section>
<section title="UDL Manual Area Addresses sub-TLV">
<t>This sub-TLV specifies the set of manualAreaAddresses of the
originating system. No other sub-TLVs are allowed in a UDL-TLV which
has this sub-TLV. Any other sub-TLVs in such a UDL-TLV are ignored on
receipt.</t>
<figure>
<artwork><![CDATA[ No. of octets
+---------------------------+
| Type (1) | 1
| (To be assigned by IANA) |
+---------------------------+
| Length | 1
+---------------------------+
: Area Address(es) :
+---------------------------+
Each Area Address has the following format:
+---------------------------+
| Address Length | 1
+---------------------------+
| Area Address | Address Length
+---------------------------+
]]></artwork>
</figure>
</section>
</section>
<section title="Adjacency Establishment">
<t>An adjacency over a UDL link may be established over a link operating
in Point-to-Point mode (including a LAN subnetwork configured to operate
in Point-to-Point mode) or a link operating in broadcast mode. Operation
in either mode is identical except for some differences in the manner of
adjacency establishment as specified in the following sub-sections.</t>
<t>IS-T utilizes the set of manualAreaAddresses advertised by IS-R in a
UDL Manual Area Address sub-TLV in combination with the UDL Intermediate
System Neighbor sub-TLV(s) to IS-T advertised by IS-R to determine the
level(s) associated with any adjacency to IS-R.</t>
<section title="Adjacency Establishment in Point-to-Point Mode">
<t>Adjacency establishment makes use of Three Way Handshake as defined
in [RFC5303] when operating in Point-to-Point mode. When operating
over a LAN subnetwork, the use of point-to-point operation over LAN as
defined in [RFC5309] is also used.</t>
<t>IS-T initiates adjacency establishment by sending Point-to-Point
IIHs over the UDL as normal i.e., including Three-Way Handshake TLV.
Note that the local circuit ID specified by IS-T need only be unique
among the set of Point-to-Point UDL links supported by IS-T on which
IS-T is at the transmit end.</t>
<t>Upon receipt of a Point-to-Point IIH IS-R creates an adjacency in
the INIT state with IS-T and advertises the existence of the adjacency
in its UDL-LSP(s) utilizing the UDL Point-to-Point Intermediate System
Neighbor sub-TLV. The Local LAN address is included if the link is a
LAN subnetwork operating in Point-to-Point mode. UDL-LSPs of the
appropriate level(s) are generated according to the type of the
adjacency with IS-T.</t>
<t>When IS-T receives the UDL-LSP(s) generated by IS-R containing the
UDL Point-to-Point Intermediate System Neighbor sub-TLV it validates
the 3 way information and, if valid, transitions its adjacency to UP
state. In subsequent Point-to-Point IIHs IS-T includes IS-R's circuit
ID information as indicated in the UDL Point-to-Point IS Neighbor
sub-TLV in its 3 way handshake TLV. A complete set of CSNPs is sent to
IS-R and IS-T propagates its LSP Database to IS-R for the level(s)
appropriate for the type of adjacency.</t>
<t>IS-R uses normal adjacency bring up rules based on the 3 way
handshake information it receives in Point-to-Point IIHs from IS-T and
advertises its IS neighbor to IS-T in the usual manner i.e. in an LSP
other than a UDL-LSP.</t>
</section>
<section title="Adjacency Establishment in Broadcast Mode">
<t>IS-T initiates adjacency establishment by sending LAN IIHs of the
appropriate level(s) over the UDL as normal. IS-T specifies itself in
the LAN ID field of the IIH, including a non-zero circuit ID. Note
that the local circuit ID specified by IS-T need only be unique among
the set of LAN UDL links supported by IS-T on which IS-T is at the
transmit end. This is because pseudo-node LSPs will never be generated
for a UDL. Operation in broadcast mode supports a UDL with a single
IS-T and multiple IS-Rs.</t>
<t>Upon receipt of a LAN IIH PDU IS-R creates an adjacency in the INIT
state with IS-T and advertises the existence of the adjacency in its
UDL-LSP(s) utilizing the UDL LAN Intermediate System Neighbor sub-TLV.
UDL-LSPs of the appropriate level(s) are generated according to the
levels supported by IS-R and IS-T.</t>
<t>When IS-T receives the UDL-LSP(s) generated by IS-R containing the
UDL LAN Intermediate System Neighbor sub-TLV(s) it validates the LANID
and, if valid, transitions its adjacency to UP state. In subsequent
LAN IIH PDUs, IS-T includes IS-R's LAN Address as indicated in the UDL
LAN IS Neighbor info. A complete set of CSNPs for the appropriate
level is sent over the circuit and IS-T also propagates its LSP
Database for the appropriate level on the circuit.</t>
<t>IS-R uses normal adjacency bring up rules based on the IS Neighbor
LAN Address information it receives in LAN IIH PDUs from IS-T and
advertises its IS neighbor to IS-T in an LSP other than a UDL-LSP.
Note that there is no pseudo-node on a UDL LAN circuit –
therefore both IS-T and IS-R MUST advertise an IS Neighbor TLV to each
other, not to a pseudo-node. This is identical to what is done on a
Point-to-Point subnetwork</t>
</section>
<section title="UDL link metric configuration">
<t>What metrics are configured on a UDL depend upon the intended use
of the UDL. If the UDL is to be used for unicast forwarding, then IS-T
should be configured with the value appropriate to its intended
preference in the network topology and IS-R should be configured with
maximum link metric (2^24 -1) as defined in [RFC5305] (assuming wide
metrics are in use). If the UDL is to be used for building a multicast
Reverse Path Forwarding tree, then IS-R should be configured with the
value appropriate to its intended preference in the network topology
and IS-T should be configured with maximum link metric (2^24 -1).If
the link is to be used for both unicast forwarding and multicast, then
it is necessary to have two different metric configurations and
perform two different SPF calculations. This may be achieved through
the use of multi-topology extensions as defined in [RFC5120]. Note
that the configured link metrics have no bearing on adjacency
establishment – they only affect the building of a Shortest Path
Tree (SPT).</t>
</section>
</section>
<section title="Adjacency Maintenance">
<t>This section defines how adjacencies are maintained once established.
Adjacency maintenance is defined without the need to send periodic
UDL-LSP updates as this would be a significant burden on the entire
network.</t>
<section title="Adjacency Maintenance by IS-T">
<t>IS-T sends IIH PDUs as normal on a UDL. As IS-R does NOT send IIH
PDUs to IS-T, IS-T maintains the adjacency to IS-R so long as all of
the following conditions are TRUE:</t>
<t><list style="symbols">
<t>IS-T has a valid UDL-LSP from IS-R which includes
Point-to-Point UDL IS Neighbor information or LAN UDL IS Neighbor
information (as appropriate) regarding the adjacency IS-R has with
IS-T on the UDL.</t>
<t>IS-T can calculate a return path rooted at IS-R to IS-T which
does not traverse the UDL on which the adjacency is associated</t>
</list></t>
<t>When either of the above conditions becomes FALSE, IS-T brings down
its adjacency to IS-R. Note that the return path calculation is only
required when a topology change occurs in the network. It therefore
need only be done in conjunction with a normal event driven SPF
calculation.</t>
<t>NOTE: Immediately after the adjacency to IS-R has come up, if the
only available return path traverses a UDL link on which the adjacency
is still in the process of coming UP, the return path check will fail.
This is possible because we bypass normal flooding rules to allow the
UDL-LSP to be flooded even when the adjacency is not UP on a UDL link
(as described later in this document). If IS-T immediately brings the
adjacency to IS-R down in this case, a circular dependency condition
arises. To avoid this, if the return path check fails immediately
after the adjacency comes up, a timer Tp is started. The timer is
cancelled when a return path check succeeds. If the timer expires,
IS-T brings down the adjacency to IS-R. A recommended value for the
timer Tp is a small multiple (e.g., "twice") of the estimated time
necessary to propagate LSPs across the entire domain.</t>
<t>Although it is unorthodox to bring up an adjacency without
confirmed two way connectivity, the extension is well grounded because
the receipt of IS-R’s UDL-LSP by IS-T is indicative of the
existence of a return path even though it cannot yet be confirmed by
examination of the LSP database. This unconfirmed two way connectivity
is a condition which we do not want to persist indefinitely - hence
the use of timer Tp.</t>
</section>
<section title="Adjacency Maintenance by IS-R">
<t>IS-R maintains its adjacency with IS-T based on receipt of IIHs
from IS-T as normal. So long as IS-T follows the rules for adjacency
maintenance described in the previous section this is sufficient.</t>
<t>Further protection against pathological behavior on the part of
IS-T (e.g., failure to perform the return path calculation after a
topology change) MAY be implemented by IS-R. When IS-R receives a CSNP
from IS-T which contains an SNP entry identifying an LSP which is not
in IS-R's Link State Database (LSDB) a timer Tf is started for each
such LSP. This includes entries which are older than, newer than, or
non-existent in IS-R's LSDB.The timer Tf is cancelled if:<list
style="symbols">
<t>The associated LSP is received by IS-R on any circuit by normal
operation of the Update process or</t>
<t>A subsequent set of CSNPs received from IS-T does not include
the LSP entry</t>
</list></t>
<t>If any timer Tf expires IS-R brings down the adjacency with
IS-T.</t>
<t>In the absence of pathological behavior by IS-T the Tf extension is
not required. Its use is therefore optional.</t>
</section>
<section title="Use of BFD">
<t>A multi-hop BFD session [RFC5883] MAY be established between IS-T
and IS-R. This can be used to provide fast failure detection. If used,
this would also make the calculation by IS-T of a return path from
IS-R to IS-T optional.</t>
</section>
</section>
<section title="Operation of the Update Process on a UDL">
<t>For purposes of LSP propagation IS-T views the UDL as if it were a
broadcast subnetwork where IS-T is the DIS. This is true regardless of
the mode of operation of the circuit (point-to-point or broadcast).
Therefore, IS-T propagates new LSPs on the UDL as they arrive but after
sending an LSP on the UDL the SRM flag for that LSP is cleared i.e. no
acknowledgement for the LSP is required or expected. IS-T also sends
periodic CSNPs on the UDL.</t>
<t>IS-R cannot propagate LSPs to IS-T on the UDL. IS-R also cannot
acknowledge LSPs received from IS-T on the UDL. In this respect IS-R
operates on the UDL in a manner identical to a non-DIS on a broadcast
circuit. If an LSP entry in a CSNP received from IS-T identifies an LSP
which is "newer than" an LSP in IS-R's LSDB, IS-R MAY request the LSP
from IS-T by sending a UDL-LSP with an LSP entry as described above.
Since IS-R's UDL-LSP(s) will be propagated throughout the network even
though the information is only of use to IS-Ts, it is recommended that
some small delay occur between the receipt of a CSNP from IS-T and the
generation of a UDL-LSP with an updated LSP entry by IS-R so as to allow
for the possible receipt of the LSP either from IS-T or on another
link.</t>
<t>If the number of LSP entries to be requested exceeds the space
available in the UDL TLV associated with the adjacency to IS-T, IS-R
MUST NOT generate multiple UDL TLVs associated with the same adjacency.
Instead it should maintain the state of SSN flags appropriately for the
LSP entries that require updates and send additional LSP entries (if
necessary) in a subsequent UDL-LSP after the previously requested
updates arrive.</t>
<t>On receipt of a UDL-LSP generated by IS-R, IS-T checks the neighbor
information in each UDL-TLV. If the information matches an existing
adjacency that IS-T has with IS-R then IS-T sets SRM flag on the UDL for
any LSPs in its LSDB which are "newer" than the corresponding entries
IS-R sent in the UDL TLV. UDL-TLVs associated with adjacencies to
routers other than IS-T are ignored by IS-T.</t>
</section>
<section title="Support for UDL on the Return Path">
<t>If all return paths from IS-R to IS-T traverse a UDL, then in order
to bring up the adjacency between IS-T and IS-R at least one of the
adjacencies on a return path UDL must already be UP. This is required
because IS-T relies on receiving the UDL-LSP(s) generated by IS-R in
order to bring up its adjacency. In order to overcome a circular
dependency in the case where multiple pairs of UDL neighbors are trying
to bring up an adjacency at the same time, an extension to LSP
propagation rules is required.</t>
<t>When a new UDL-LSP is received by any IS which has one or more active
UDLs on which it is operating as an IS-T, the set of neighbors other
than the local system which are advertised in UDL-TLVs in the received
UDL-LSP is extracted - call this UDL-LSP-ISN-SET. A return path from the
originating IS-R to each neighbor in the UDL-LSP-ISN-SET is calculated.
If there is no return path to one or more neighbors in this set periodic
propagation of that UDL-LSP on all UDLs on which the local system acts
as IS-T is initiated regardless of the state of an adjacency on that
UDL. Periodic transmission of that UDL-LSP continues until a return path
to all neighbors in the UDL-LSP-ISN-SET exists. This calculation is
redone whenever the UDL-LSP is updated and when a topology change in the
network occurs as a result of updates to the LSDB. Note that periodic
retransmission is only done on UDLs on which the local system acts as
IS-T.</t>
<t>If the network is partitioned the lack of a return path from a given
IS-R to a given IS-T may persist. It is therefore recommended that the
periodic retransmission employ an exponential backoff timer such that
when the partition persists the periodic retransmission period is long
enough so as to not represent a significant burden. It is recommended
that the periodic retransmission be initially set to the locally
configured CSNP interval. Note that periodic retransmission is only
performed on UDL links and if an IS-R has previously received the same
UDL-LSP it will silently ignore the retransmission since the UDL-LSP
will already be in its LSDB. Unnecessary reflooding of the retransmitted
UDL-LSP beyond the UDL does not occur.</t>
<t>IS-R MUST accept and propagate UDL-LSPs received on a UDL even when
there is no adjacency in the UP state on the UDL circuit. Flooding of
UDL-LSPs by IS-R uses normal flooding rules. LSPs received by IS-R on
the UDL which do NOT include UDL TLVs are discarded unless the adjacency
is UP (normal processing).</t>
<t>This extension allows establishment of an adjacency on a UDL even
when the return path transits another UDL which is also in the process
of bringing up an adjacency. The periodic nature of the flooding is
meant to compensate for the unreliability of the flooding. After the
adjacency is UP, IS-R can request LSPs from IS-T by putting LSP entries
into UDL-LSPs – but that ability is not available until the
adjacency is UP.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requires the definition of a new IS-IS TLV to be
reflected in the "IS-IS TLV Codepoints" registry:</t>
<t><figure>
<artwork><![CDATA[Type Description IIH LSP SNP Purge
---- ------------ --- --- --- -----
11 Unidirectional Link Information N Y N Y
]]></artwork>
</figure></t>
<t>This document requires that a new IANA registry be created to control
the assignment of sub-TLV code points to be advertised within a
Unidirectional Link Information TLV. The registration procedure is
"Expert Review" as defined in [RFC5226]. The following sub-TLVs are
defined by this document. Values are suggested values subject to
assignment by IANA.</t>
<figure>
<artwork><![CDATA[Value Description
----- ------------------------------
1 Manual Area Addresses
6 LAN IS Neighbor
9 LSP Entry
240 Point-to-Point IS Neighbor
]]></artwork>
</figure>
<t><figure>
<artwork><![CDATA[
]]></artwork>
</figure></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security concerns for IS-IS are addressed in [IS-IS], [RFC5304], and
[RFC5310].</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The idea of supporting IS-IS on UDLs without using tunnels or
encapsulation was originally introduced in the US patent "Support of
unidirectional link in IS-IS without IP encapsulation and in presence of
unidirectional return path" (patent number: 7,957,380), by Sina
Mirtorabi, Abhay Kumar Roy, Lester Ginsberg.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.5226'?>
<?rfc include='reference.RFC.5303'?>
<?rfc include='reference.RFC.5305'?>
<reference anchor="IS-IS">
<front>
<title>Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473), ISO/IEC 10589:2002, Second Edition.</title>
<author fullname="ISO "International Organization for Standardization""/>
<date month="Nov" year="2002"/>
</front>
</reference>
</references>
<references title="Informational References">
<?rfc include='reference.RFC.5120'?>
<?rfc include='reference.RFC.5304'?>
<?rfc include='reference.RFC.5309'?>
<?rfc include='reference.RFC.5310'?>
<?rfc include='reference.RFC.5883'?>
<?rfc include='reference.RFC.6232'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:43:14 |