One document matched: draft-kompella-mpls-unnum-00.txt

Network Working Group                             Kireeti Kompella
Internet Draft                                    Juniper Networks
Expiration Date: January 2001                        Yakov Rekhter
                                                     Cisco Systems


               Traffic Engineering with Unnumbered Links

                    draft-kompella-mpls-unnum-00.txt


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


2. Abstract

   Traffic Engineering currently does not take into account unnumbered
   links.  There are two issues: carrying information about unnumbered
   links in IS-IS and OSPF; and including unnumbered links when
   signalling.  This document addresses these two issues.












draft-kompella-mpls-unnum-00.txt                                [Page 1]

Internet Draft      draft-kompella-mpls-unnum-00.txt           July 2000


3. Overview

   Traffic Engineering currently does not take into account unnumbered
   links (i.e., links that do not have IP addresses).  However, not
   numbering links is useful, if not critical, in many environments; the
   reasons include conserving IP addresses, and reducing management
   overhead.  This document only covers point-to-point links that are
   unnumbered.

   There are two issues: carrying Traffic Engineering information about
   unnumbered links in IS-IS and OSPF (see [ISIS-TE] and [OSPF-TE]); and
   including unnumbered links when signalling (see [RSVP-TE]).  This
   document proposes a simple means of solving the former (modeled on
   how OSPF carries unnumbered link information for router link
   advertisements), and a simple extension to the RSVP Explicit Route
   Object for the latter.


4. Interface Identifiers

   If links are not identified by an IP address, they need some other
   identifier.  We assume that each unnumbered link on a Label Switched
   Router (LSR) is given a unique 16-bit identifier.  The scope of this
   identifier is the LSR to which the link belongs; moreover, the
   ISIS/OSPF and RSVP modules on an LSR must agree on interface
   identifiers.  A good candidate for the interface identifier is the
   SNMP IfIndex of the interface.


5. Carrying Unnumbered Links in IS-IS and OSPF

   In IS-IS, the extended IS reachability TLV contains an IPv4 Interface
   Address, which normally identifies an IPv4 address for an interface.
   If the interface being advertised for Traffic Engineering purposes is
   unnumbered, the IPv4 Interface Address is set to the router ID of the
   advertising LSR.  The extended IS reachability TLV also contains an
   IPv4 Neighbor Address, which normally identifies an IPv4 address of
   the neighboring LSR on a link.  If the interface being advertised for
   Traffic Engineering purposes is unnumbered, the first two octets of
   the IPv4 Neighbor Address are set to zero, and the next two octets
   are set to the Interface ID of the unnumbered interface.  The rest of
   the Traffic Engineering information remains unchanged.

   In OSPF, the Link sub-TLV of the Opaque Traffic Engineering TLV
   contains a Local Interface IP Address, which normally identifies the
   IPv4 address for an interface.  If the interface being advertised for
   Traffic Engineering purposes is unnumbered, the Local Interface
   Address is set to the router ID of the advertising LSR.  The Link



draft-kompella-mpls-unnum-00.txt                                [Page 2]

Internet Draft      draft-kompella-mpls-unnum-00.txt           July 2000


   sub-TLV of the Opaque Traffic Engineering TLV also contains a Remote
   Interface IP Address, which normally identifies the neighbor's IPv4
   address for the interface.  If the interface being advertised for
   Traffic Engineering purposes is unnumbered, the first two octets of
   the Remote Interface IP Address are set to zero, and the next two
   octets are set to the Interface ID of the unnumbered interface.  The
   rest of the Traffic Engineering information remains unchanged.


6. Signalling Unnumbered Links in EROs

   A new subobject of the Explicit Route Object (ERO) is used to signal
   unnumbered links.  This subobject has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |     Interface ID (16 bits)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This subobject MUST be strict (i.e., the L bit MUST be 0).  The Type
   is 3 (Unnumbered Interface ID).  The Length is 4.  The Interface ID
   is interpreted in the context of the previous node in the path (i.e.,
   the node identified by the previous subobject in the ERO, which MUST
   identify a unique node), or, if this is the first subobject in the
   ERO, in the context of the start of the path.  The next node in the
   path is the node at the other end of the interface identified by the
   Interface ID.


7. Security Considerations

   This document raises no new security concerns for IS-IS, OSPF or
   RSVP.


8. References

   [ISIS-TE] Smit, H., and Li, T., "IS-IS extensions for Traffic
   Engineering", draft-ietf-isis-traffic-01.txt (work in progress)

   [OSPF-TE] Katz, D., and Yeung, D., "Traffic Engineering Extensions to
   OSPF", draft-katz-yeung-ospf-traffic-01.txt (work in progress)

   [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan,
   V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
   draft-ietf-mpls-rsvp-lsp-tunnel-06.txt (work in progress)




draft-kompella-mpls-unnum-00.txt                                [Page 3]

Internet Draft      draft-kompella-mpls-unnum-00.txt           July 2000


9. Author Information


Kireeti Kompella
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
e-mail: kireeti@juniper.net

Yakov Rekhter
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: yakov@cisco.com





































draft-kompella-mpls-unnum-00.txt                                [Page 4]