One document matched: draft-bishnoi-mpls-mldp-opaque-types-01.txt
Differences from 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: April 2010
IJsbrand Wijnands
Cisco Systems, Inc.
October 26, 2009
LDP Multipoint Opaque Value Element Types
draft-bishnoi-mpls-mldp-opaque-types-01.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 April 26, 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Bishnoi, et. al Expires April 26, 2010 [Page 1]
Internet-Draft LDP Multipoint Opaque Types October 2009
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
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 0...............................4
4.2. Opaque Value Element Type 1...............................5
4.3. Opaque Value Element Type 2...............................6
5. Security Considerations........................................7
6. IANA Considerations............................................7
7. Conclusions....................................................7
8. References.....................................................7
8.1. Normative References......................................7
8.2. Informative References....................................8
9. Acknowledgments................................................8
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
Bishnoi, et. al Expires April 26, 2010 [Page 2]
Internet-Draft LDP Multipoint Opaque Types October 2009
Element is used. Both types of FEC elements contain MP Opaque Value
Element in type-length-value format.
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.
Bishnoi, et. al Expires April 26, 2010 [Page 3]
Internet-Draft LDP Multipoint Opaque Types October 2009
This is accomplished by defining new opaque value element types and
the associated formats of the value field.
2. Terminology
This document uses the terminology defined in [MLDP], [MVPN] and
[BGP-MPN].
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 [RFC-2119].
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 0
This document recommends to use type 0 to manage the identifier space
for manual or statically provisioned general purpose P2MP and MP2MP
LSPs. Mapping of traffic to MP LSPs provisioned with this type is
outside the scope of this document.
Statically provisioned P2MP and MP2MP LSPs preferably should have a
common identifier space across implementations. Recommendation to use
type 0 for all statically provisioned P2MP and MP2MP LSPs would allow
common identifier space to be available across all implementations.
This would avoid incompatibility of identifier space across multiple
vendor implementations and allow seamless replacement of root node
without changing configuration on all leaf nodes.
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= 00 | Length |LSP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Identifier (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bishnoi, et. al Expires April 26, 2010 [Page 4]
Internet-Draft LDP Multipoint Opaque Types October 2009
Figure 2.
. AII Type = 0x00
. Length = length of value field in octets. The length is set to
4.
. LSP Identifier = A 4-octet field containing a value that is
unique at a root node.
4.2. Opaque Value Element Type 1
Opaque Value Element Type 1 is defined to be used exclusively for
dynamically provisioned 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-MPN].
If Tunnel type is set to LDP P2MP LSP then it carries P2MP FEC
Element with Opaque Value Element type 1. If tunnel type is set to
mLdp MP2MP LSP then it carries MP2MP FEC Element with Opaque Value
Element type 1.
The Opaque Value Element type 1 uses a 32 bit Global-ID to create
globally unique values of P-Tunnels. The encoding of opaque value
element type 1 is shown in Figure 3. 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= 01 | Length | Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global ID (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bishnoi, et. al Expires April 26, 2010 [Page 5]
Internet-Draft LDP Multipoint Opaque Types October 2009
Figure 3.
. AII Type = 0x01
. 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.
4.3. Opaque Value Element Type 2
Opaque Value Element Type 2 is defined to be used exclusively for
statically provisioned MP LDP Tunnels for MVPNs [MVPN]. This enables
the opaque value space to be managed and used entirely for static
MVPNs without any risk of overlap with other applications that use
LDP MP Tunnels.
Statically provisioned P2MP and MP2MP LSPs for MVPN is based on the
encoding as specified in RFC2685 in combination with a PMSI ID. PSMI
ID number 0 indicates a Mi-PMSI, non-zero numbers indicate a S-PMSI.
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= 2 | Length | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI (contd.) | VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index (contd.) | PMSI ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PMSI ID (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4.
. AII Type = 0x02
. Length = length of value field in octets. The length is set to
11.
. OUI = Organization Unique Identifier. The length is set to 3
bytes.
Bishnoi, et. al Expires April 26, 2010 [Page 6]
Internet-Draft LDP Multipoint Opaque Types October 2009
. VPN Index = Identifying the VPN according to the OUI. The length
is set to 4 bytes.
. PMSI ID = Mi-PMSI or S-PMSI identifier. The length is set to 4
bytes.
This type of Opaque Value Element is mapped to traffic by procedures
defined in [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 Types
(0x00 and 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.
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.
[RFC2685] Fox, B., Gleeson, B., ''Virtual Private Networks
Identifier'', RFC 2685, September 1999.
Bishnoi, et. al Expires April 26, 2010 [Page 7]
Internet-Draft LDP Multipoint Opaque Types October 2009
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
[MVPN-BGP] 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
Pranjal Kumar Dutta
Alcatel-Lucent
701 E Middlefield Road,
Mountain View, CA 94043
USA
Email: pranjal.dutta@alcatel-lucent.com
Bishnoi, et. al Expires April 26, 2010 [Page 8]
Internet-Draft LDP Multipoint Opaque Types October 2009
IJsbrand Wijnands
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
Email: ice@cisco.com
Bishnoi, et. al Expires April 26, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-21 12:59:17 |