One document matched: draft-bishnoi-mpls-mldp-opaque-types-00.txt
MPLS Working Group Sandeep Bishnoi
Internet Draft Pranjal Kumar Dutta
Intended status: Standards Track Alcatel-Lucent
Expires: January 2010
IJsbrand Wijnands
Cisco Systems, Inc.
July 6, 2009
LDP Multipoint Opaque Value Element Types
draft-bishnoi-mpls-mldp-opaque-types-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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
This Internet-Draft will expire on January 6, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Bishnoi, et. al Expires January 6, 2010 [Page 1]
Internet-Draft LDP Multipoint Opaque Types July 2009
Abstract
[MLDP] describes extensions to the Label Distribution Protocol (LDP)
for setup of point to multi-point (P2MP) and multipoint-to-multipoint
(MP2MP) Label Switched Paths (LSPs). LDP forwarding equivalence class
(FEC) elements used to establish P2MP and MP2MP LSPs include type-
length-value (TLV) fields that carry information meaningful to
Ingress LSRs and Leaf LSRs and are termed as Opaque Value Elements in
[MLDP]. This document defines Opaque Value Element structure to be
used for provisioning P2MP and MP2MP Provider tunnels (P-Tunnels) for
Multicast Virtual Private Network (MVPN). It is envisioned that this
would be useful for security and manageability of P-Tunnels used for
MVPN from the ones provisioned for other applications and vice-versa.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................4
3. Conventions used in this document..............................4
4. Structure for the New Opaque Value Element Type................4
4.1. Opaque Value Element Type 1...............................4
4.2. Opaque Value Element Type 2...............................4
5. Security Considerations........................................5
6. IANA Considerations............................................5
7. Conclusions....................................................5
8. References.....................................................6
8.1. Normative References......................................6
8.2. Informative References....................................6
9. Acknowledgments................................................6
1. Introduction
[MLDP] defines the extensions to LDP and procedures for establishing
P2MP and MP2MP LSPs in Multi-Protocol Label Switch (MPLS) networks.
Throughout this document P2MP and MP2MP LSPs are collectively
referred as multi-point (MP) LSPs. When a MP LSP is setup, the LDP
signaling messages include a forwarding equivalence class (FEC)
element that uniquely identifies the MP LSP in LDP.
For the setup of a P2MP LSP with LDP, P2MP FEC Element is used as a
FEC Element in LDP FEC TLV. Similarly for MP2MP LSP, MP2MP FEC
Element is used. Both types of FEC elements contain MP Opaque Value
Element in type-length-value format.
Bishnoi, et. al Expires January 6, 2010 [Page 2]
Internet-Draft LDP Multipoint Opaque Types July 2009
The LDP MP Opaque Value Element defined in [MLDP] is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1.
The use of the opaque value in MP FEC Element provides the
flexibility to structure an MP FEC Element to best fit the needs of a
particular application or provisioning model.
An opaque value that is globally unique would facilitate MP LSP
management and security in large inter-AS (autonomous system) and
inter-provider environments. Providers would not have to worry about
opaque value overlap during provisioning LDP MP LSPs for various
applications. Globally unique opaque values per application types
could aid in troubleshooting as well.
For example, a provider may provision P2MP LSPs in its network by
manually provisioning at the root and the leaf nodes. The same root
node may also initiate dynamic provisioning of P2MP LSPs for MVPN
P-Tunnels by using BGP auto-discovery (AD) procedures described in
[BGP-MVPN]. For manageability and security reasons, it is required to
have a separate Opaque Value Element space available entirely for
manual provisioning and another space for allocation and distribution
by BGP AD procedures for MVPNs.
This document defines opaque value structures based on [MLDP] that:
. Ensures uniqueness among applications if desired by provider.
This will facilitate provisioning of LDP MP Tunnels for various
applications without conflict of Opaque Value Element space.
This is accomplished by defining new opaque value element types and
the associated formats of the value field.
Bishnoi, et. al Expires January 6, 2010 [Page 3]
Internet-Draft LDP Multipoint Opaque Types July 2009
2. Terminology
This document uses the terminology defined in [MLDP], [MVPN] and
[BGP-MVPN].
3. Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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 [RFC2119].
4. Structure for the New Opaque Value Element Type
[MLDP] defines the format of P2MP and MP2MP FEC Element and the use
and semantics of Opaque Value Elements.
4.1. Opaque Value Element Type 1
Opaque Value Element Type 1 has been defined by [MLDP] that contains
a generic lsp identifier encoded as 32-bit integer. This document
recommends to use type 1 to manage the identifier space for manual or
statically provisioned P2MP and MP2MP LSPs. Mapping of traffic to MP
LSPs provisioned with this type is outside the scope of this
document.
4.2. Opaque Value Element Type 2
Opaque Value Element Type 2 is defined to be used exclusively for
provisioning MP LDP Tunnels for MVPNs [BGP-MVPN]. This enables the
opaque value space to be managed and used entirely for BGP MVPNs
without any risk of overlap with other applications that use LDP MP
Tunnels.
[BGP-MVPN] defines and uses a new BGP attribute, called P-Multicast
Service Interface Tunnel (PMSI Tunnel) attribute that is distributed
with MVPN AD routes in BGP. The attribute carries a Tunnel Type and
Tunnel Identifier of the P-Tunnel bound to MCAST-VPN-NLRI [BGP-MVPN].
If Tunnel type is set to LDP P2MP LSP then it carries P2MP FEC
Element with Opaque Value Element type 2. If tunnel type is set to
mLdp MP2MP LSP then it carries MP2MP FEC Element with Opaque Value
Element type 2.
Bishnoi, et. al Expires January 6, 2010 [Page 4]
Internet-Draft LDP Multipoint Opaque Types July 2009
The Opaque Value Element type 2 uses a 32 bit Global-ID to create
globally unique values of P-Tunnels. The encoding of opaque value
element type 2 is shown in Figure 2. below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type= 02 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2.
. AII Type = 0x02
. Length = length of value field in octets. The length is set
to 4.
. Global ID = This is a 4-octet field containing a value that is
unique within P-Tunnels initiated by BGP AD at a root node.
This type of Opaque Value Element is mapped to traffic by procedures
defined in [BGP-MVPN] and is outside the scope of this document.
5. Security Considerations
The same security considerations apply as for the base LDP
specification, as described in [RFC5036] and MP LDP specification, as
described in [MLDP].
6. IANA Considerations
This document requires allocation of new Opaque Value Element Type
0x02.
7. Conclusions
Further types of Opaque Value Elements are a subject of future study
and would be defined in later versions based on requirements.
Bishnoi, et. al Expires January 6, 2010 [Page 5]
Internet-Draft LDP Multipoint Opaque Types July 2009
8. References
8.1. Normative References
[MLDP] I. Minei, K., Kompella, I. Wijnands, B. Thomas, "Label
Distribution Protocol Extensions for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp-06.txt, May 2008
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP
IP VPNs", draft-ietf-l3vpn-2547bis-mcast-08.txt,
March 5 2009
[BGP-MVPN] R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter,
C.Kodeboniya, "BGP Encodings for Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-07.txt,
April 2009
9. Acknowledgments
The authors would like acknowledge the comments and suggestions from
Wim Henderickx and Mustapha Aissaoui.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Sandeep Bishnoi
Alcatel-Lucent
701 E Middlefield Road,
Mountain View, CA 94043
USA
Email: sandeep.bishnoi@alcatel-lucent.com
Bishnoi, et. al Expires January 6, 2010 [Page 6]
Internet-Draft LDP Multipoint Opaque Types July 2009
Pranjal Kumar Dutta
Alcatel-Lucent
701 E Middlefield Road,
Mountain View, CA 94043
USA
Email: pdutta@alcatel-lucent.com
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Bishnoi, et. al Expires January 6, 2010 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-21 13:04:32 |