Internet Draft Network Working Group Internet Draft Alex Mondrus Expiration Date: December 1999 Alcatel USA June 1999 MPLS Capable attribute draft-mondrus-mpls-attribute-00.txt 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 areworking 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 anytime. 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. Abstract This document proposes an additional attribute to identify MPLS-capable interfaces. When this attribute is used, it allows the source-head of MPLS tunnel to identify MPLS topology for source-route calculation. This document does not specify any protocol changes. It is important to emphasize that proposed technique is relatively simple and relies on existing IGPs and MPLS signaling protocols. 1. Introduction When MPLS signaling sets up a LSP, it uses layer-3 topology, so if the source-head of a LSP calculates the source-route to a destination, it does not take into an account if the IP interface is MPLS-capable. When MPLS-capable attribute is used, it allows to automatically detect the IP interfaces which support MPLS. Therefore, a network administrator could rely on this feature to identify the MPLS topology. The proposed attribute would be flooded using an IGP. Both IS-IS and OSPF can be used for this purpose. 2. Architectural proposal Let's assume a network X consists of a Y number of IP devices. Let's also assume that a network administrator configures only portion of his IP topology to use label forwarding. Mondrus [Page 1] On this network X, an IGP conveys all constraint routing (CR) attributes required for the source-head to calculate a LSP path to a particular destination. One of the flooded attributes is MPLS-capable attribute. When the source-head of a LSP receives the CRs, it should be able to determine the MPLS topology. So if there is requirement to identify MPLS topology, the MPLS-capable attribute could be a good candidate for this purpose. Based on the pruned CR topology, the source-routed path can be calculated at the source-head, so MPLS signaling should be forwarded to MPLS capable interfaces. 3. Acknowledgments The author would like to acknowledge Liwen Wu, Benjamin Abarbanel, Senthil Venkatachalam and Patrick Sichien for their comments 4. References: [1] IGP Requirements for Traffic Engineering with MPLS; http://www.ietf.org/internet-drafts/draft-li-mpls-igp-te-00.txt [3] Extensions to RSVP for LSP Tunnels; http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-02.txt [4] Constraint-Based LSP Setup using LDP; http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-01.txt [5] IS-IS extensions for Traffic Engineering; http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-00.txt [6] OSPF Extensions for Traffic Engineering; http://www.ietf.org/internet-drafts/draft-yeung-ospf-traffic-00.txt [7] The OSPF OpaqueLSA Option; ftp://ftp.isis.edu.in-notes/rfc2370.txt 5. Author' Address Alex Mondrus Alcatel USA 44983 Knoll Square Ashburn,VA 20147 USA Tel: 1(703)724-2749 E-mail: Alex.Mondrus@adn.alcatel.com [Page 2] --------------------------------------------------------------------- Network Working Group Internet Draft Alex Mondrus Expiration Date: December 1999 Alcatel USA June 1999 MPLS Capable attribute draft-mondrus-mpls-attribute-00.txt 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 areworking 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 anytime. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document proposes an additional attribute to identify MPLS-capable interfaces. When this attribute is used, it allows the source-head of MPLS tunnel to identify MPLS topology for source-route calculation. This document does not specify any protocol changes. It is important to emphasize that proposed technique is relatively simple and relies on existing IGPs and MPLS signaling protocols. 1. Introduction When MPLS signaling sets up a LSP, it uses layer-3 topology, so if the source-head of a LSP calculates the source-route to a destination, it does not take into an account if the IP interface is MPLS-capable. When MPLS-capable attribute is used, it allows to automatically detect the IP interfaces which support MPLS. Therefore, a network administrator could rely on this feature to identify the MPLS topology. The proposed attribute would be flooded using an IGP. Both IS-IS and OSPF can be used for this purpose. 2. Architectural proposal Let's assume a network X consists of a Y number of IP devices. Let's also assume that a network administrator configures only portion of his IP topology to use label forwarding. Mondrus [Page 1] On this network X, an IGP conveys all constraint routing (CR) attributes required for the source-head to calculate a LSP path to a particular destination. One of the flooded attributes is MPLS-capable attribute. When the source-head of a LSP receives the CRs, it should be able to determine the MPLS topology. So if there is requirement to identify MPLS topology, the MPLS-capable attribute could be a good candidate for this purpose. Based on the pruned CR topology, the source-routed path can be calculated at the source-head, so MPLS signaling should be forwarded to MPLS capable interfaces. 3. Acknowledgments The author would like to acknowledge Liwen Wu, Benjamin Abarbanel, Senthil Venkatachalam and Patrick Sichien for their comments 4. References: [1] IGP Requirements for Traffic Engineering with MPLS; http://www.ietf.org/internet-drafts/draft-li-mpls-igp-te-00.txt [3] Extensions to RSVP for LSP Tunnels; http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-02.txt [4] Constraint-Based LSP Setup using LDP; http://www.ietf.org/internet-drafts/draft-ietf-mpls-cr-ldp-01.txt [5] IS-IS extensions for Traffic Engineering; http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-00.txt [6] OSPF Extensions for Traffic Engineering; http://www.ietf.org/internet-drafts/draft-yeung-ospf-traffic-00.txt [7] The OSPF OpaqueLSA Option; ftp://ftp.isis.edu.in-notes/rfc2370.txt 5. Author' Address Alex Mondrus Alcatel USA 44983 Knoll Square Ashburn,VA 20147 USA Tel: 1(703)724-2749 E-mail: Alex.Mondrus@adn.alcatel.com [page 2]