Internet Draft 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]