One document matched: draft-raggarwa-ppvpn-mpls-ip-gre-sig-00.txt
Network Working Group Rahul Aggarwal (Redback Networks)
Internet Draft Robert Raszuk (Cisco Systems, Inc)
Expiration Date: June 2003
Signaling MPLS in IP or MPLS in GRE Encapsulation
Capability
draft-raggarwa-ppvpn-mpls-ip-gre-sig-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, except that the right to
produce derivative works is not granted.
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.
1. Abstract
This document proposes a lightweight mechanism for signaling a PE
router's capability to encapsulate MPLS using dynamic GRE and/or IP.
This is applicable when a MPLS packet is tunnelled using a dynamic
GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. For
instance the MPLS packet may be a 2547 based MPLS VPN packet
[2547bis] or a layer 2 packet transported using MPLS [MARTINI].
Adding such a mechanism has several benefits. It helps in blackhole
avoidance and eases transitioning from MPLS tunneling based
Layer 3/Layer 2 VPNs to GRE/IP tunneling based Layer 3/Layer 2 VPNs
(and vice versa). Such a mechanism is needed where a network may be
using MPLS and GRE (or IP) for tunneling, at the same time, in 2547
based or Layer 2 VPNs. It can help in encapsulation selection when
multiple tunneling technologies are supported. It can also be used to
enhance the security of the network backbone.
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 1]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
2. 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].
3. Summary for Sub-IP Area
3.1. Related documents
See the Reference Section
3.2. Where does it fit in the Picture of the Sub-IP Work
This work fits in the PPVPN WG.
3.3. Why is it Targeted at this WG
[2547bis] is a product of the PPVPN WG. This document specifies a
mechanism that proposes a lightweight mechanism for signaling a PE
router's capability to encapsulate MPLS using dynamic GRE and/or IP.
This is applicable when a 2547 based MPLS VPN packet is tunnelled
using a dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between
PE routers. Since the procedures described in this document are
directly related to [2547bis], it would be logical to target
this document at the PPVN WG.
4. Mechanism
2547 VPNs, Layer 2 VPNs or point to point Layer 2 transport over MPLS
may use dynamic GRE or IP encapsulation for tunneling traffic across a
network backbone. This document uses the term 'soft GRE' to refer to
dynamic GRE encapsulation. If a PE router is using soft GRE or IP
encapsulation for tunneling MPLS VPN traffic, across the backbone, it is
not possible currently for it to dynamically learn the encapsulation
capability of the remote PE router. In the context of 2547 based VPNs
this PE router does not know the MPLS in soft GRE or MPLS in IP
encapsulation capability of the BGP next-hop to which the traffic is
destined. This document proposes a simple signaling mechanism by way
of which this PE router can learn the MPLS in soft GRE or MPLS in IP
encaspulation capability of the remote PE routers. This is achieved
by propagating this information in BGP or in LDP.
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 2]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
4.1 BGP Extension
We define a BGP opaque extended community attribute that can be
attached to a BGP NLRI advertisement to indicate the MPLS
encapsulation capabilities of such a NLRI. It is referred to as the
MPLS encapsulation extended community attribute. This is transitive
across the Autonomous System boundary. The MPLS Encapsulation
community is of an extended type. The value of the high-order octet
of the Type Field is 0x03. The value of the low-order octet of the
Type field for this community is 0x01 [BGP-EXT-COM].
The MPLS encapsulation extended community attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 |Sub-Type = 0x01| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Encapsulation Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encapsulation bits indicate all the encapsulations supported and are
encoded in the two least significant octets:
01 - MPLS in soft GRE encapsulation
02 - MPLS in IP encapsulation
4.2 LDP Extension
MPLS in soft GRE or MPLS in IP encapsulation capability may need to be
advertised when LDP signaling is used for establishing pseudo wires
[MARTINI] or for Layer 2 VPNs [LDP-SIG]. When BGP is used as a
discovery mechanism for Layer 2 VPNs BGP extensions proposed in 4.1
should be suffcient for determining the right encapsulation to use.
If this is not the case, the encapsulation capability is advertised
in LDP. This is done at the time of LDP session establishment. We
define a LDP MPLS encapsulation Session TLV for this purpose. This
TLV is advertised as an optional parameter in the LDP Initialization
message. This optional parameter has a type of 0x0506 (Subject to
IANA approval) and has the following format:
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 3]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Type = 0x0506 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Encapsulation Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encapsulation bits indicate all the encapsulations supported by the PE
originating the Initialization message. They are encoded in the two
least significant octets:
01 - MPLS in soft GRE encapsulation
02 - MPLS in IP encapsulation
4.3 Applicability of BGP and LDP Extensions
The decision to use BGP or LDP for advertising the MPLS in soft
GRE or MPLS in IP encapsulation capability depends on the
application. For 2547 based VPNs this information is advertised in
BGP advertisements using the MPLS encapsulation extended community.
This is also true for BGP based Layer 2 VPNs [BGP-L2VPN]. BGP may be
used as an auto-discovery mechanism for Layer 2 VPNs established
using LDP signaling [BGP-AUTO]. In this case MPLS encapsulation
extended community can be added to the BGP auto-discovery
advertisements to convey the encapsulation capability. There may
be cases when LDP is used for establishing pseudo wires and Layer 2
VPNs [MARTINI, LDP-SIG], and BGP is not used as an auto-discovery
protocol. In this case the encapsulation capability can be advertised
using the Encapsulation TLV in the LDP Initialization message.
5. Usage
We describe the usage of this signaling enhancement in the context
of 2547, though its equally applicable to Layer 2 VPNs. With this
mechanism a PE can 'signal' its MPLS in IP or MPLS in soft GRE
encapsulation capability to other PEs. A PE (say PE1) now
has two pieces of information while determining if VPN routes learned
from a remote PE (say PE2) are eligible for MPLS in IP or MPLS in
soft GRE encapsulation :
o Is PE1 configured to support MPLS in IP or MPLS in soft GRE
encapsulation
o Does PE2 support MPLS in IP or MPLS in soft GRE encapsulation.
This is learned via the mechanism described above.
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 4]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
If both the above are true, the VPN route can be installed in the VRF
and tunnelled using IP or soft GRE. Else the VPN route cannot be
tunnelled using IP or soft GRE. However it can still be tunnelled
using MPLS or some other tunnelling mechanism. If PE2 supports
multiple encapsulations, this mechanism can be used to pick one of
the encapsulations based on local policy at PE1. In certain
implementations BGP may propagate the capability of PE2 to
the local RIB. Hence the local RIB can determine if a particular
next-hop is eligible for MPLS in IP or MPLS in soft GRE enapsulation.
6. Benefits
This mechanism adds several benefits:
6.1. Blackhole Avoidance
Without knowing the MPLS in IP or MPLS in soft GRE capability of the
remote PE, the local PE, if configured for MPLS in IP or MPLS in soft
GRE, can start sending IP or GRE encapsulated MPLS traffic to the
remote PE even if the remote PE doesn't support MPLS in IP or MPLS in
soft GRE encapsulation. This can happen if the remote PE is running
an incorrect software version or if its simply not configured to
support the expected encapsulation. This can result in blackholing
the MPLS traffic. This mechanism avoids that as the local PE will
never send IP or GRE encapsulated VPN traffic to the remote PE unless
the remote PE advertises that its MPLS in IP or MPLS in soft GRE
capable.
6.2. Co-existing MPLS and IP or Soft GRE tunneling
It is conceivable that in a network providing 2547 based VPN service
some of the PEs may support MPLS in soft GRE or MPLS in IP while
others may support only MPLS tunnelling. Further still its
conceivable that one may wish to use soft GRE tunnelling for certain
VPN routes and MPLS tunnelling for other VPN routes destined to the
same PE. An example would be a co-existing IPSec over GRE and MPLS
tunneling service for VPN-routes.
Hence if LDP is used for MPLS tunneling, a given PE (say PE1) may be
configured to run LDP and support soft GRE at the same time. The
reason being that some of the remote PEs can only use MPLS tunneling.
However now there is no way for a remote PE (say PE2) that supports
soft GRE to know the tunneling tecnology to use while sending MPLS
VPN traffic to PE1. If it prefers using soft GRE it cannot be sure
that PE1 supports soft GRE and it cannot rely on the LDP FECs
received from PE1 to make this decision. The mechanism proposed in
this document solves this problem as PE2 can learn the soft GRE
capability of PE1.
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 5]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
VPN routes advertised by a PE may be advertised with different
next-hops if this PE wants the remote PEs to use different tunnelling
technologies for different next-hops. Hence this PE may wishe to
receive GRE encapsulated VPN traffic for some VPN routes and MPLS
encapsulated VPN traffic for other VPN routes. It is possible to
advertise the soft GRE capability only for certain VPN routes,
associated with a particular next-hop.
6.3. Transitioning
An operator may wish to transition some or all of the routers in a
2547 based network from using MPLS based tunneling to soft GRE or IP
based tunneling and vice-versa. This approach greatly simplifies this
transition. Once the remote soft GRE or IP encapsulation capability
is known a PE can determine if it wishes to use MPLS or GRE or IP to
encapsulate the traffic. Without this mechanism an operator
transitioning certain routers from MPLS based tunneling to GRE based
tunneling needs to enable soft GRE on all such routers before MPLS
can be turned off on any of the routers. Similarly, without this
mechanism, an operator transitioning certain routers from soft GRE
based tunneling to MPLS tunneling needs to enable MPLS on all such
routers before soft GRE can be turned off on any of the routers.
6.4. Security Enhancement
This approach can be used to enhance the security of the network
backbone when MPLS in IP or MPLS in soft GRE encapsulation is used.
In this case a router should accept MPLS in IP or MPLS in soft GRE
encapsulated packets only from routers in the provider's backbone.
This implies that the egress router should verify the source of the
tunneled packet, ensuring that it is sent by a trusted router. This
would require the trusted source addresses to be configured. The
mechanism described in this document simplifies this as the remote PE
addresses associated with the MPLS encapsulation capabilities can
be considered as trusted addresses and used for verification when the
tunnelled packets are received.
7. Deployment Considerations
It is recommended that an implementation provide a configuration
option to trigger the announcement of a PE's encapsulation
capabilities in BGP or LDP. This will help in selective deployment
of this mechanism.
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 6]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
8. IANA Considerations
This document requires the use of a BGP extended community and a LDP
MPLS encapsulation TLV. We have assigned the next available values to
each of these from the respective number spaces. The sub-type for the
BGP transitive opaque MPLS encapsulation extended community is
assigned value of 0x01. The type of the LDP MPLS encapsulation TLV is
assigned a value of 0x0506. These values are subject to IANA approval.
9. Security Considerations
This document does not introduce any new security issues. The security
issues identified in [BGP-EXT-COM], [RFC3036], [MPLS-IP-GRE] and
[2547bis] are still relevant.
10. Acknowledgements
We would like to thank Enke Chen, Jenny Yuan, Naiming Shen, Acee Lindem,
and Ravi Chandra for their valuable contributions to this document and
for helping in evolving this mechanism.
Thanks to Yakov Rekhter for his comments and valuable suggestions. We
would also like to thank Eric Rosen and Francois Le Faucheur for their
comments.
11. References
[BGP-EXT-COM] S.R. Sangli et. al., "BGP Extended Communities
Attribute", draft-ietf-idr-bgp-ext-communities-05.txt.
[RFC3036] L. Andersson et. al., "LDP Specification", Request For
Comments 3036.
[MPLS-IP-GRE] T. Worster et. al., "Encapsulating MPLS in IP or GRE",
draft-rosen-mpls-in-ip-or-gre-00.txt.
[2547bis] Rosen, E. et. al., "BGP/MPLS VPNs," Internet-draft
draft-ietf-ppvpn-rfc2547bis-04.txt, January 2002.
[MARTINI] L. Martini. et. al., "Transport of Layer 2 Frames Over
MPLS", draft-ietf-pwe3-control-protocol-00.txt.
[BGP-L2VPN] K. Kompella et. al., "Layer 2 VPNs over Tunnels",
draft-kompella-ppvpn-l2vpn-02.txt.
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 7]
Internet Draft draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt November 2002
[BGP-AUTO] Ould-Brahim et. al., "Using BGP as an Auto-Discovery
Mechanism for Network based VPNs",
draft-ietf-ppvpn-bgpvpn-auto-02.txt.
[LDP-SIG] E. Rosen, "LDP-based Signaling for L2VPNs",
draft-rosen-ppvpn-l2-signaling-02.txt.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12. Author Information
Rahul Aggarwal
Redback Networks
350 Holger Way
San Jose, CA 95134
Email: rahul@redback.com
Robert Raszuk
Cisco Systems, Inc.
Al Jerozolimskie 146C
02-305 Warsaw, Poland
Email: rraszuk@cisco.com
draft-raggarwa-ppvn-mpls-ip-gre-sig-00.txt [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-22 09:45:13 |