Network Working Group Albert Tian Internet Draft Naiming Shen Expiration Date: Aug 2004 Redback Networks Feb 2004 Multi-Instance(MI) support in LDP draft-tian-mpls-mi-ldp-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 Many of the routing protocols today can support multiple topologies or multiple instances [ISISMT] [OSPFV3] [OSPFMT]. In such an environment, prefix, address family, and topology/instance together define an FEC. But the current LDP specificaiton is not sufficient to allow multi-topology/multi-instance to share the same LDP session. In this document we introduce a concept of "Label Binding Instance" to LDP so that FECs can be unambiguiously identified in a multi- topology/multi-instance routing environment. Tian and Shen [Page 1] Internet Draft draft-tian-mpls-mi-ldp-00.txt Jan 2004 3. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4. Introduction In the LDP specification [RFC3036], a received label mapping for a prefix or host address FEC can be used for forwarding/switching only when the LSR that originated the label mapping is in the set of nexthops of the FEC according to routing. A prefix FEC element or a host address FEC element is identified by the prefix/host address and the address family. This assumes routing only produces one set of nexthops for a prefix or host address in a given address family. Extension to ISIS has been proposed in [ISISMT] to support multiple topologies. OSPF Version 3 [OSPFV3] supports multiple routing instances. Several extensions have also been proposed to support multiple topologies in OSPFv3 [OSPFMT]. When running LDP in a multi-topology/multi-instance environment, it is necessary to identify which topology/instance a prefix belongs, so that the correct set of nexthops can be selected. This can be achieved by associating a prefix with a "Label Binding Instance" in the FEC. 5. Label Binding Instances Here we introduce a concept of "Label Binding Instance" to accomadate multiple routing topologies, instances, or user defined applications. Each label binding instance has a unique instance Id in a MPLS domain. Prefix, address family and label binding instance together define a prefix FEC. Routing topology ID or instance ID can be used as label binding instance ID. In this case, prefix FECs advertised in such a label binding instance SHOULD use the corresponding routing topology or instance to verify the nexthop. When a prefix exists in multiple routing topologies or instances, then multiple LDP LSPs can be established for the prefix, one for each topology or instance. [RFC3036] can be think of as a specification handling label bindings for the default label binding instance with a special instance Id 0, Tian and Shen [Page 2] Internet Draft draft-tian-mpls-mi-ldp-00.txt Jan 2004 which corresponds to the default unicast topology, or the default routing instance. 6. LDP Multi-Instance FEC (M-FEC) We introduce a new LDP Multi-Instance FEC TLV. It may appear any where an LDP FEC TLV may appear. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| Multi-Instance FEC (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID | Reserved (Must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Element 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC Element n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Instance ID A 16-bit value uniquely identifis a label binding instance in a MPLS domain. The Instance ID applies to all FEC elements in the TLV. Reserved Reserved for future extension. The Multi-Instance FEC TLV must be discarded if this field is not zero. The other fields in this TLV have the same definition as FEC TLV as defined [RFC3036] section 3.4.1. Tian and Shen [Page 3] Internet Draft draft-tian-mpls-mi-ldp-00.txt Jan 2004 7. Procedures If the receiving LSR does not support Multi-Instance FEC, then the Multi-Instance FEC TLV must be discarded silently. FEC TLV defined in section 3.4.1 of [RFC3036] implicitly specify FEC with default label binding instance ID 0. A Multi-Instance FEC TLV with Instance Id 0 explicitly specifies FEC with label binding instance ID 0. This TLV can carry extra flags that are not available in the original FEC TLV. A router may chose to advertise both M-FEC TLV with instance ID 0 and vanilla FEC TLV for compatibility reasons. When multi-topology/multi-instance routing is used together with LDP, the mapping between routing topologies/instances and LDP label binding instances should be consistant across the routing domain to avoid undesirable forwarding behavior. 8. IANA Considerations This document defines a new LDP Multi-Instance FEC TLV. The type code needs to be assigned by IANA. 9. Security Considerations This document introduces no new security concerns to LDP or other specifications referenced in this document. 10. Acknowledgments The authors would like to thank Bob Thomas for reviewing the paper. Tian and Shen [Page 4] Internet Draft draft-tian-mpls-mi-ldp-00.txt Jan 2004 11. References [RFC3036] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and B. Thomas, "LDP Specification", RFC 3036, January 2001. [OSPFV3] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [ISISMT] T. Prezgienda, N. Shen, N. Sheth, draft-ietf-isis-wg-multi-topology-06.txt, work in progress. [OSPFMT] S. Mirtorabi, et al, draft-mirtorabi-ospfv3-af-alt-00.txt, work in progress. 12. Author Information Albert Tian Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: tian@redback.com Naiming Shen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 Email: naiming@redback.com Tian and Shen [Page 5]