Subject: isis over ipv4 update ...

From: Antoni Przygienda <[email-masked]>
Date: Tue, 01 Dec 1998 21:33:06 -0500

new version after comments FYI .. We left the interoperability section
in 
for discussion but intend to drop it after the meeting ...

		tahnk you

	--- tony

Internet Engineering Task Force       A. Bansal, T. Przygienda, A. Patel
INTERNET DRAFT                                    Fore, Bell Labs/Lucent
                                                              1 Nov 1998

                            IS-IS over IPv4
                  <draft-ietf-isis-wg-over-ip-01.txt>

Status of This Memo
   This document is an Internet Draft, and can be found as
   draft-ietf-isis-wg-over-ip-01.txt in any standard internet drafts
   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
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material, or to cite them other than as a
   ``working draft'' or ``work in progress.''
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract
   This draft describes an optional implementation technique within
   IS-IS [ISO90, Cal90a, Cal90b] used today by several ISPs for routing
   within their clouds.  IS-IS is an interior gateway routing protocol
   developed originally by OSI and used with IP extensions as IGP. This
   draft describes how to encapsulate IS-IS packets in IPv4 [Pos81]
   format.  Such an encapsulation has many advantages, one of those
   being the possibility to run integrated IS-IS on anything that
   understands IPv4, including avian carriers [Wai90].

1. Introduction
   Encapsulation of IS-IS as defined in ISO 10589 [ISO90, Cal90a,
   Cal90b] uses directly over Link Layer protocols as opposed to IP
   routing protocols [Moy97] that are encapsulated over IP directly.

   By defining an encapulsation of IS-IS in IP, we save on special OSI

Bansal et al.                Expires 1 May 1999                 [Page 1]
^L
Internet Draft                IS-IS over IPv4                 1 Nov 1998

   encapsulation on several media types.  Such an encapsulation would
   solve fragmentation problems of large LSPs and remove the necessity
   for OSI PPP extensions [Kat92] when IS-IS is run over negotiated
   PPP links.  Additionally, on certain media, such as p2p ATM links,
   no LLC/SNAP encapsulation is necessary to provide multi-protocol
   routing, allowing for gains in efficiency.

2. Encapsulation of IS-IS and ISO 9542 packets over IP
   IS-IS is encapsulated directly over the Internet Protocol's
   network layer.  IS-IS packets are therefore encapsulated by IP
   and local data-link headers.  Within this encapsulation, IS-IS
   packets are propagated as usual, however without the appropriate
   link-layer fields on point-to-point links and with a special internal
   encapsulation described in section 3 on broadcast media.

   IS-IS does not normally transmit a way to transmit packets larger
   than MTU size, This proposal would allow it to use IP fragmentation
   when transmitting packets larger than the network MTU. If necessary,
   the length of IS-IS packets 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) can usually be split into several
   separate protocol packets, without loss of functionality.  This is
   recommended; IP fragmentation should be avoided whenever possible.
   Using this reasoning, an attempt should be made to limit the sizes
   of IS-IS over IP packets sent over links to 1472 bytes including
   all media specific encapsulation unless Path MTU Discovery is being
   performed [MD90] or the router configuration allows for larger PDU
   sizes.  IIHs must be sent with the DF bit and use a size of the IP
   MTU less 20 bytes for the IP header.
   The other important features of IS-IS in IP's IP encapsulation are:

    -  Use of IP multicast.  Some IS-IS in IP messages are multicast,
       when sent over broadcast networks.  Three distinct IP multicast
       addresses are used.  Packets sent to these multicast addresses
       should never be forwarded; they are meant to travel a single hop
       only.  To ensure that these packets will not travel multiple
       hops, their IP TTL must be set to 1.

          IPAllL1ISs

             OSI multicast value of this address was O1-80-C2-00-00-14.
             This multicast address has been assigned the IP address
             value 224.0.0.?  for IP encapsulated IS-IS. All routers

Bansal et al.                Expires 1 May 1999                 [Page 2]
^L
Internet Draft                IS-IS over IPv4                 1 Nov 1998

             running L1 IS-IS in IP should be prepared to receive
             packets sent to this address.  Hello packets are always
             sent to this destination.  Also, certain IS-IS in IP
             protocol packets are sent to this address during the
             flooding procedure.

          IPAllL2ISs

             OSI multicast value of this address was O1-80-C2-00-00-15.
             This multicast address has been assigned the IP address
             value 224.0.0.?  for IP encapsulated IS-IS. All routers
             running L2 IS-IS in IP should be prepared to receive
             packets sent to this address.  Hello packets are always
             sent to this destination.  Also, certain IS-IS in IP
             protocol packets are sent to this address during the
             flooding procedure.

          IPAllIntermediateSystems

             OSI multicast value of this address was 09-00-2B-0O-00-05.
             This multicast address has been assigned the IP address
             value 224.0.0.?  for IP encapsulated IS-IS. All routers
             running IS-IS in IP should be prepared to receive packets
             sent to this address.  ISO 9542 is using this address.

    -  IS-IS in IP is IP protocol number ??.  This number has been
       requested with the Network Information Center.  IP protocol
       number assignments are documented in [RP94].

       Note:  For development purposes, IP Protocol number 9 (Private
       IGP protocol number) [RP94] will be used until an official number
       is granted.

    -  All IS-IS in IP routing protocol packets are sent using the
       normal service TOS value of binary 0000 defined in [Alm92].

    -  Routing protocol packets are sent with IP precedence set to
       Internetwork Control.  IS-IS in IP protocol packets should be
       given precedence over regular IP data traffic, in both sending
       and receiving.  Setting the IP precedence field in the IP
       header to Internetwork Control [Pos81] may help implement this
       objective.

Bansal et al.                Expires 1 May 1999                 [Page 3]

Internet Draft                IS-IS over IPv4                 1 Nov 1998

3. Internal Encapsulation

   On point-to-point links no MAC addresses are used by IS-IS. Therefore
   the Intradomain Routeing Protocol Discriminator or ISO 9542 Network
   Layer Protocol Identifier starts directly after the IP header.  For
   P2P link running over PPP, the Payload format will consist of PPP
   header, followed by the IP header and NLPID as indicated in the
   following figure:

       +------------+-----------+----------------+
       | PPP Header | IP Header | NLPID|ISIS PDU |
       +------------+-----------+----------------+

   For P2P ATM links using VC muxing, the payload format must not
   include a PPP header:

       +-------------+-----------+-----------------+
       | AAL5 Header | IP Header | NLPID|ISIS  PDU |
       +-------------+-----------+-----------------+

   In the case of broadcast media, MAC addresses are used for adjacency
   maintainance.  It would be rather painful to assume that an IS-IS
   implementation can have access to MAC headers, therefore when sending
   IS-IS encapsulated on broadcast networks an encapsulation header
   preeceds the Intradomain Routeing Protocol Discriminator.  It is
   essentially an LLC/SNAP [Hei93] encapsulation indicating bridged
   traffic with a contained routed OSI frame.  From both the possible
   PIDs the one indicating LAN FCS is prefferable and can replace
   optional checksums as described in [?].  The following figure
   illustrates the encapsulation for 802.3 type PDUs.

Payload Format for Bridged Ethernet/802.3 PDUs

               +-------------------------------+
               |       LLC  0xAA-AA-03         |
               +-------------------------------+
               |        OUI 0x00-80-C2         |
               +-------------------------------+
               |         PID 0x00-07           |

Bansal et al.                Expires 1 May 1999                 [Page 4]
^L
Internet Draft                IS-IS over IPv4                 1 Nov 1998

               +-------------------------------+
               |         PAD 0x00-00           |
               +-------------------------------+
               |    MAC destination address    |
               +-------------------------------+
               |    MAC source address         |
               +-------------------------------+
               |           Length              |
               +-------------------------------+
               |         LLC DSAP 0xFE         |
               +-------------------------------+
               |         LLC SSAP 0xFE         |
               +-------------------------------+
               |         LLC CNTL 0x03         |
               +-------------------------------+
               |             NLPI              |
               +-------------------------------+
               |                               |
               |   (remainder of ISO frame)    |
               |                               |
               +-------------------------------+

4. Interoperability with Devices without IP Encapsulation
   Normally, an interface will be configured to operate in either
   ISO or IS-IS in IP mode, for migration and interoperability with
   unknown/older devices a clear migration path is however preferable,
   as is controlled behavior in cases of misconfiguration.  To allow for
   operation in both modes, the following procedures are proposed in
   case an interface is configured to operate in both modes.

    -  in INIT all IS-IS and 9542 PDUs are sent and received in both
       encapsulations.

    -  in case any IP encapsulated frame has been received at any point
       in time on the interface, only IP encapsulated PDUs are sent and
       received on the interface.  No standard PDUs are received until
       the interface falls back into INIT.

    -  in case any traditionally encapsulated frame has been received
       in INIT, the interface starts to send traditionally encapsulated
       frames only with the exception that every 10th IIH is sent both
       in traditional as well as in IP encapsulation.  The interface

Bansal et al.                Expires 1 May 1999                 [Page 5]
^L
Internet Draft                IS-IS over IPv4                 1 Nov 1998

       continues to receive both, the traditionally encapsulated frames
       as well as listen to IP encapsulated frames.  This ensures that
       the routers will try to ``climb up'' to IP encapsulation as the
       prefered mode of operation as soon as possible.

5. Acknowledgments
   The encapsulation description part has been "borrowed" from a
   well-known RFC [Moy97] with the author's consent.  Tony Li, Mike
   Shand, Rajesh Varadarajan, Jeff Swinton and Stacy Smith commented on
   the proposal.

6. Security Consideration
   ISIS security applies to the work presented.  No specific security
   issues with the proposed solutions are known.  Things like IPSec may
   influence the work in strange and unknown ways ;-)

References
   [Alm92]  P. Almquist.  Type of Service in the Internet Protocol
            Suite.  INTERNET-RFC, Internet Engineering Task Force, July
            1992.

   [Cal90a] R. Callon.  OSI ISIS Intradomain Routing Protocol.
            INTERNET-RFC, Internet Engineering Task Force, February
            1990.

   [Cal90b] R. Callon.  Use of OSI ISIS for Routing in TCP/IP and Dual
            Environments.  INTERNET-RFC, Internet Engineering Task
            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
            Information Exchange between Systems - Intermediate System
            to Intermediate System Routing Exchange Protocol for
            Use in Conjunction with the Protocol for Providing the
            Connectionless-Mode Network Service.  ISO, 1990.

Bansal et al.                Expires 1 May 1999                 [Page 6]
^L
Internet Draft                IS-IS over IPv4                 1 Nov 1998

   [Kat92]  D. Katz.  Rfc 1377, The PPP OSI Network Layer Control
            Protocol (OSINLCP).  Internet Engineering Task Force,
            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,
            July 1997.

   [Pos81]  J. Postel.  Rfc 791, rfc Internet Protocol.  Internet
            Engineering Task Force, September 1981.

   [RP94]   J. Reynolds and J. Postel.  Rfc 1700, Assigned Numbers.
            Internet Engineering Task Force, October 1994.

   [Wai90]  D. Waitzman.  Rfc 1149, standard for the Transmission of
            IP Datagrams on Avian Carriers.  Internet Engineering Task
            Force, April 1990.

Authors' Addresses

Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Ajay Patel
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
[email-masked]

Atul Bansal
FORE Systems,
1595 Spring Hill Rd
Vienna, VA 22181
[email-masked]

Bansal et al.                Expires 1 May 1999                 [Page 7]