< draft-ietf-isis-wg-over-ip-00.txt   draft-ietf-isis-wg-over-ip-01.txt >
Internet Engineering Task Force A. Bansal, T. Przygienda, A. Patel Internet Engineering Task Force A. Bansal, T. Przygienda, A. Patel
INTERNET DRAFT Fore, Bell Labs/Lucent INTERNET DRAFT Fore, Bell Labs/Lucent
20 Jan 1998 May 1998
IS-IS over IPv4 IS-IS over IPv4
<draft-ietf-isis-wg-over-ip-00.txt> <draft-ietf-isis-wg-over-ip-01.txt>
Status of This Memo Status of This Memo
This document is an Internet Draft, and can be found as This document is an Internet-Draft and is in full conformance with
draft-ietf-isis-wg-over-ip-02.txt in any standard internet drafts all provisions of Section 10 of RFC2026.
repository. 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 Internet-Drafts are working documents of the Internet Engineering
months. Internet Drafts may be updated, replaced, or obsoleted by Task Force (IETF), its areas, and its working groups. Note
other documents at any time. It is not appropriate to use Internet that other groups may also distribute working documents as
Drafts as reference material, or to cite them other than as a Internet-Drafts.
``working draft'' or ``work in progress.'' Internet-Drafts are draft documents valid for a maximum of six months
Please check the I-D abstract listing contained in each Internet and may be updated, replaced, or obsoleted by other documents at
Draft directory to learn the current status of this or any other any time. It is inappropriate to use Internet- Drafts as reference
Internet Draft. 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.
Abstract Abstract
This draft describes an optional implementation technique within This draft describes an optional implementation technique within
IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
within their clouds. IS-IS is an interior gateway routing protocol within their clouds. IS-IS is an interior gateway routing protocol
developed originally by OSI and used with IP extensions as IGP. This developed originally by OSI and used with IP extensions as IGP. This
draft describes how to encapsulate IS-IS packets in IPv4 [Pos81] draft describes how to encapsulate IS-IS packets in IPv4 [Pos81]
format. Such an encapsulation has many advantages, one of those format. Such an encapsulation has many advantages, one of those
being the possibility to run integrated IS-IS on anything that being the possibility to run integrated IS-IS on anything that
understands IPv4, including avian carriers [Wai90]. understands IPv4, including avian carriers [Wai90]. Encapsulation of
IS-IS PDUs in IPv6 is outside the scope of this document.
1. Introduction 1. Introduction
Encapsulation of IS-IS as defined in ISO 10589 [ISO90, Cal90a, Encapsulation of IS-IS as defined in ISO 10589 [ISO90, Cal90a,
Cal90b] uses directly over Link Layer protocols as opposed to IP Cal90b] uses directly over Link Layer protocols as opposed to IP
routing protocols [Moy97] that are encapsulated over IP directly. routing protocols [Moy97] that are encapsulated over IP directly.
By defining an encapsulation of IS-IS in IP, we save on special OSI By defining an encapsulation of IS-IS in IP, we save on special OSI
encapsulation on several media types. Such an encapsulation would encapsulation on several media types. Such an encapsulation would
solve fragmentation problems of large LSPs and remove the necessity solve fragmentation problems of large LSPs and remove the necessity
for OSI PPP extensions [Kat92] when IS-IS is run over negotiated for OSI PPP extensions [Kat92] when IS-IS is run over negotiated
skipping to change at page 2, line 28 skipping to change at page 2, line 30
IS-IS does not normally provide a way to transmit packets larger IS-IS does not normally provide a way to transmit packets larger
than MTU size. This proposal allows to use IP fragmentation when than MTU size. This proposal allows to use IP fragmentation when
transmitting such packets. If necessary, the length of IS-IS packets transmitting such packets. If necessary, the length of IS-IS packets
over IP can be up to 65,535 bytes (including the IP header). The over IP can be up to 65,535 bytes (including the IP header). The
IS-IS packet types that are likely to be large (LSPs, CSNPs, PSNPs) IS-IS packet types that are likely to be large (LSPs, CSNPs, PSNPs)
can usually be split into several separate protocol packets, without can usually be split into several separate protocol packets, without
loss of functionality. This is recommended; IP fragmentation SHOULD loss of functionality. This is recommended; IP fragmentation SHOULD
be avoided whenever possible since it can lead to different problems, be avoided whenever possible since it can lead to different problems,
such as loss of fragments causing the retransmission of complete IP such as loss of fragments causing the retransmission of complete IP
packets. Following rules apply: packets. Following rules apply:
- IIHs MUST have the size of [InterfaceMTU - IP headersize] (1) - IIHs MUST not exceed the size of [InterfaceMTU - IP headersize]
and have the DF bit set. IIH's TTL MUST be set to 1 to prevent (1) and have the DF bit set. MTU size padding rules should be
them from traveling multiple hops. followed as described in ISO 10589.
- SNPs on IP encapsulated interfaces MUST NOT be larger than - SNPs MUST NOT be larger than the respective originatingLSPBufferSize.
the minimum of [InterfaceMTU - IP headersize] and respective
originatingLSPBufferSize. - SNPs MUST be sent allowing IP fragmentation (DF bit not set).
- SNPs SHOULD NOT be larger than the minimum of [InterfaceMTU -
IPheadersize] and respective originatingLSPBufferSize.
- LSP fragments MAY BE built with a size up to the value of - LSP fragments MAY BE built with a size up to the value of
corresponding originatingLSPBufferSize. corresponding originatingLSPBufferSize.
___________________________________________
1. not of maximum of Buffer and DataLinkSize used normally
- LSP fragments MUST NOT be larger than the respective - LSP fragments MUST NOT be larger than the respective
originatingLSPBufferSize. originatingLSPBufferSize.
___________________________________________
1. not of maximum of Buffer and DataLinkSize used normally
- LSPs MUST be sent allowing IP fragmentation (DF bit not set). - LSPs MUST be sent allowing IP fragmentation (DF bit not set).
- LSP fragments SHOULD NOT exceed the size of the minimum of - LSP fragments SHOULD NOT exceed the size of the minimum of
dataLinkBlockSize and respective originatingLSPBufferSize. dataLinkBlockSize and respective originatingLSPBufferSize.
This set of rules allows to configure a network with respective This set of rules allows to configure a network with respective
originatingLSPBufferSize larger than some interfaces' MTUs. originatingLSPBufferSize larger than some interfaces' MTUs.
In a mixed environment, care must be taken that respective In a mixed environment, care must be taken that respective
originatingLSPBufferSize does net exceed the MTU size of interfaces originatingLSPBufferSize does net exceed the MTU size of interfaces
without IP encapsulation. without IP encapsulation.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
+-------------+-----------+-----------------+ +-------------+-----------+-----------------+
| AAL5 Header | IP Header | NLPID|ISIS PDU | | AAL5 Header | IP Header | NLPID|ISIS PDU |
+-------------+-----------+-----------------+ +-------------+-----------+-----------------+
Figure 2: Encapsulation of ISIS frames over ATM Figure 2: Encapsulation of ISIS frames over ATM
In the case of broadcast media, MAC addresses are used for adjacency In the case of broadcast media, MAC addresses are used for adjacency
identification. It is rather painful from the implementation identification. It is rather painful from the implementation
perspective to assume that an IS-IS must have access to MAC headers perspective to assume that an IS-IS must have access to MAC headers
when receiving frames. On the other hand, introducing an artificial when receiving frames. However, based on the observation that
`bridging' encapsulation header preceding the Intradomain Routeing ethernets have at least one IP address assigned, MAC address
Protocol Discriminator within the routed frame was perceived as necessary for adjacency maintenance can be built algorithmically
a very bulky solution. As yet another approach, based on the using the source address of the IP packet received. To prevent
observation that ethernets always have at least one IP address, collisions with universally administered addresses, the addresses
MAC address necessary for adjacency maintenance could be built are designated by having bit one in byte zero of the MAC set to 1 to
algorithmically using the source address of the IP packet received. indicate locally administered address as specified by the according
However, this would necessitate e.g. the allocation of a 2-byte IEEE standard. When receiving an IP encapsulated ISIS PDU, the
prefix within the 802.2/3 MAC space. Given the difficulties artificial MAC address is assumed to consist (in network order) of
surrounding each of these solutions, no special encapsulation is 4 bytes of source IP address aligned as least significant bytes,
defined for the ethernet case and the protocol implementation is ``locally administered'' bit being set and all remaining bits being
either required to received the complete frame, including layer 2 zero. Figure 3 visualizes such an address for a source IP address
encapsulation or obtain the appropriate MAC address from the source 128.127.128.1.
IP address using an interface to the lower layers of the IP stack.
0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6 0 2 4 6
+--------+--------+--------+--------+--------+--------+
|01000000|00000000|10000000|01111111|10000000|00000001|
+--------+--------+--------+--------+--------+--------+
Figure 3: Artificial MAC for IP address 128.127.128.1
When operating on an interface encapsulating IS-IS within IP,
encapsulated PDUs MUST be sent with a constant IP source address.
Any change of the IP address on the interface MUST be considered
equivalent to change of MAC address in ISO mode. In all places in
which MAC addresses are being used in ISO mode, source IP address
MUST be used to compute artificial MACs when sending and parsing
received PDUs.
Any PDU received on IP encapsulated broadcast interface and
containing MACs with either the ``locally administered'' bit not
being set or any of the remaining bits in the first two bytes being
set SHOULD be discarded. Any configuration in which an interface
uses a MAC that would be equivalent to such an algorithmic MAC being
generated on another interface within the same system SHOULD be
considered a misconfiguration.
4. Interoperability with Devices without IP Encapsulation 4. Interoperability with Devices without IP Encapsulation
An interoperability solution for devices using IP encapsulation and An interoperability solution for devices using IP encapsulation and
OSI encapsulation of ISIS frames would be only useful if it could OSI encapsulation of ISIS frames would be only useful if it could
significantly ease the migration path in the existing networks. significantly ease the migration path in the existing networks.
Given the fact that graceful migration is not a paramount issue for Given the fact that graceful migration is not a paramount issue for
existing networks and any solution would invariable lead to the existing networks and any solution would invariable lead to the
problem of partitioning of broadcast media, such a solution is not problem of partitioning of broadcast media, such a solution is not
defined. defined.
5. Acknowledgments 5. Acknowledgments
The encapsulation description part has been "borrowed" from a The encapsulation description part has been "borrowed" from a
well-known RFC [Moy97] with the author's consent. Tony Li, Mike well-known RFC [Moy97] with the author's consent. Tony Li, Dave
Shand, Henk Smit, Rajesh Varadarajan, Jeff Swinton, Stacy Smith gave Katz, Mike Shand, Henk Smit, Rajesh Varadarajan, Jeff Swinton, Stacy
many constructive comments. Smith provided constructive comments.
6. Security Consideration 6. Security Consideration
ISIS security applies to the work presented. No specific security ISIS security applies to the work presented. No specific security
issues with the proposed solutions are known. Things like IPSec may issues with the proposed solutions are known. Things like IPSec may
influence the work in strange and unknown ways ;-) influence the work in strange and unknown ways ;-)
References References
[Alm92] P. Almquist. Type of Service in the Internet Protocol [Alm92] P. Almquist. Type of Service in the Internet Protocol
skipping to change at page 6, line 32 skipping to change at page 7, line 13
1992. 1992.
[Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol.
INTERNET-RFC, Internet Engineering Task Force, February INTERNET-RFC, Internet Engineering Task Force, February
1990. 1990.
[Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Environments. INTERNET-RFC, Internet Engineering Task Environments. INTERNET-RFC, Internet Engineering Task
Force, December 1990. Force, December 1990.
[Hei93] J. Heinanen. Rfc 1483, Multiprotocol Encapsulation over ATM
Adaptation Layer 5. Internet Engineering Task Force, July
1993.
[ISO90] ISO. Information Technology - Telecommunications and [ISO90] ISO. Information Technology - Telecommunications and
Information Exchange between Systems - Intermediate System Information Exchange between Systems - Intermediate System
to Intermediate System Routing Exchange Protocol for to Intermediate System Routing Exchange Protocol for
Use in Conjunction with the Protocol for Providing the Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990. Connectionless-Mode Network Service. ISO, 1990.
[Kat92] D. Katz. Rfc 1377, The PPP OSI Network Layer Control [Kat92] D. Katz. Rfc 1377, The PPP OSI Network Layer Control
Protocol (OSINLCP). Internet Engineering Task Force, Protocol (OSINLCP). Internet Engineering Task Force,
November 1992. November 1992.
[MD90] J. Mogul and S. Deering. Rfc 1191, Path MTU Discovery.
Internet Engineering Task Force, November 1990.
[Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force,
July 1997. July 1997.
[Pos81] J. Postel. Rfc 791, rfc Internet Protocol. Internet [Pos81] J. Postel. Rfc 791, rfc Internet Protocol. Internet
Engineering Task Force, September 1981. Engineering Task Force, September 1981.
[RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers. [RP94] J. Reynolds and J. Postel. Rfc 1700, Assigned Numbers.
Internet Engineering Task Force, October 1994. Internet Engineering Task Force, October 1994.
[Wai90] D. Waitzman. Rfc 1149, standard for the Transmission of [Wai90] D. Waitzman. Rfc 1149, standard for the Transmission of
 End of changes. 14 change blocks. 
50 lines changed or deleted 69 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/