IP VPN Realization using MPLS Tunnels
draft-casey-vpn-mpls-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Robert Eros , Dr. Liam Casey , Ian Cunningham | ||
| Last updated | 1998-11-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This Internet Draft describes a method of using MPLS to realize a provider IP VPN capability. The approach described here exploits the Label Switch Path (LSP) mesh implicitly established between all edge routers in an MPLS domain [4]. It uses 2 levels of LSP tunneling. The outer or base level is the hop by hop LSP tunnels that interconnect all VPN Border (Label Switch) Routers (VBR\022s). The 'bottom of label stack', nested level provides logically single hop tunnels between VBR\022s. For each IP VPN, single hop nested tunnels are established between all VBR's serving that particular VPN. The draft outlines the components involved in the MPLS IP VPN architecture and outlines how they interact. The proposed realization is caste in terms of the VPN areas introduced in [1] and is geared to take advantage of a virtual router (VR) capability in the VBR's. This results in a powerful and flexible method of providing an IP VPN service that meets the requirements outlined in [3]. Also described are two extensions: offering MPLS VPN service to the customer (rather than IP service) and using Label Switching to traverse VPN areas[1].
Authors
Robert Eros
Dr. Liam Casey
Ian Cunningham
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)