One document matched: draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt
Differences from draft-ouldbrahim-ppvpn-ovpn-requirements-00.txt
Provider Provisioned VPN Hamid Ould-Brahim
Internet Draft Nortel Networks
Expiration Date: July 2003 Yakov Rekhter
Juniper Networks
Luyuan Fang
AT&T
Yong Xue
UUNET/WorldCom
Ananth Nagarajan
Sprint
Eric Mannie
Ebone
Marco Carugi
France Telecom R&D
John Drake
Calient Networks
Dimitri Papadimitriou
Alcatel
December 2002
Service Requirements for Optical Virtual Private Networks
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026 [RFC-2026], 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-
Ould-Brahim, et. al 1
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
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.
Abstract
This document addresses service requirements for provider
provisioned optical virtual private network
The intent of this document is to include the OVPN work as part
of PPVPN charter. A VPN service model based on optical
connectivity has a lot of functional elements in common with
other models already chartered in PPVPN.
Inclusion of this topic in the charter will facilitate
convergence and maximize reusability of common techniques to
provide VPN service functions independently of the VPN
connectivity level. That is also a global objective of the
PPVPN standardization effort.
1. Sub-IP ID Summary
This document addresses service requirements for provider
provisioned port based optical virtual private network.
RELATED DOCUMENTS
"GVPN: Generalized Provider-provisioned Port-based VPNs using
BGP and GMPLS ", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-00.txt
See also the reference section.
WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
Fits the PPVPN box.
WHY IS IT TARGETED AT THIS WG
This WG is looking at port based VPN using IP based building
blocks. This work is within the scope of a port-based optical
VPN.
2. Introduction
Ould-Brahim, et al. July 2003 [Page 2]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
This document addresses service requirements for provider
provisioned optical virtual private network. The scope of this
draft is related to port-based VPNs only.
The intent of this document is to include the OVPN work as part
of PPVPN charter.
3. Conventions used in this document
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 [2].
4. Optical VPN Reference Model
Consider a service provider network that consists of devices
such as Optical Network Element (ONE) which may be Optical
Cross Connects (OXCs), or SONET/SDH Cross Connects. We
partition these devices into P (provider) ONEs and PE (provider
edge) ONEs. The P ONEs are connected only to the ONEs within
the provider's network. The PE ONEs are connected to the ONEs
within the provider network, as well as to the devices outside
of the provider network. We'll refer to such other devices as
Client Edge Devices (CEs). An example of a CE would be a
router, or a SONET/SDH Cross Connect, or an Ethernet switch.
Figure 1 highlights the Optical VPN reference model as
described above
+---+ +---+
| P |....| P |
+---+ +---+
PE / \ PE
+-----+ +-----+ +--+
| | | |----| |
+--+ | | | | |CE|
|CE|----+-----+ | |----| |
+--+\ | | | +--+
\ +-----+ | |
\ | | | | +--+
\| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1 Optical VPN reference Model
Ould-Brahim, et al. July 2003 [Page 3]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
A CE is connected to a PE ONE via one or more links, where each
link may consist of one or more channels or sub-channels (e.g.,
wavelength, or wavelength and timeslot respectively, or just
timeslot). A link has two end-points - one on CE and one on PE
ONE. In the context of this document we'll refer to the former
as "CE port", and to the latter as "PE ONE port".
5. General Service Requirements
The basic unit of the OVPN service is an optical or TDM
connection between a pair of CEs, or to be more precise,
between a port on one CE and a port on another CE. If a port on
CE has multiplexing capabilities, the same port could be used
to connect to more than one (remote) CE ports.
1) The OVPN service SHOULD support VPN membership at the
granularity as fine as a single port/link/channel (e.g. an
"AUG-4" in an STM-64 interface, or more simply a VC-4).
2) The OVPN service SHOULD support treating ports and links as
logical constructs that are used to represent grouping of
physical resources per OVPN. The OVPN service MAY be built
using link bundling mechanism.
3) The OVPN service SHOULD provide support for a broad spectrum
of OVPN topologies, such as hub-and-spoke, full mesh,
arbitrary, etc.
4) The OVPN service SHOULD support either direct control where
an in band control channel exists with the data bearing links
and channels between the CE and PE ONE pair, or indirect
control where an out of band control channel exists for the
data bearing links and channels between the CE and PE ONE pair.
Moreover, an OVPN service SHOULD allow multiple data links with
one associated control channel/link.
5) In general, addressing, signaling and routing interaction
between the provider's network and client networks are based on
the standard control plane interconnection models currently
under development in the IETF.
6) For the control and provisioning of the OVPN service, both
distributed control mechanisms and centralized control
mechanisms SHOULD be supported to accommodate the service
control and management platforms used by different carriers.
7) As far as possible, the OVPN service SHOULD be based on
technologies developed in the PPVPN Working Group and other
relevant IETF working groups.
Ould-Brahim, et al. July 2003 [Page 4]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
6. Service Provider Network Requirements
8) The OVPN service SHOULD allow links from different OVPNs to
be connected to a given PE ONE.
9) The OVPN service SHOULD provide mechanisms by which ports on
a PE ONE are partitioned into (disjoint) sets, with each set
representing ports for a given OVPN.
10) The OVPN service SHOULD not require all ports on a given PE
ONE to have the same characteristics.
11) To simplify operations and for better scalability and
stability purposes, the OVPN service SHOULD provide mechanisms
by which a given PE ONE that has at least one port associated
with a given OVPN could learn about all other ports of that
OVPN, even if these ports are on other PE ONEs, and even if
these other PE ONEs belong to some other service providers.
These mechanisms SHOULD be provided per OVPN basis and on a
network wide scale from service provider perspective.
12) Furthermore, as a value added service, a service provider
MAY provide a CE that has at least one port in a given OVPN
with the information related to all other CE ports of that
OVPN, including the information about various properties of
these ports.
13) When a service provider network denies connectivity between
a pair of CE ports, the service provider network MUST provide a
reason (to at least one of these CEs) for denying the
connectivity.
14) The OVPN service MAY assume that each PE ONE port has an
identifier that is unambiguous at least with the Service
Provider network that this port belongs to. And in the case
where the OVPN service spans multiple (interconnected) service
providers, it is assumed that this identifier is unambiguous
across all PE ONE ports of these service providers.
15) The OVPN service SHOULD allow PE ONE ports facing the
customer devices to be identified by either network layer
addresses (e.g., IPv4 addresses), or by a combination of PE ONE
identifier and a port/interface index (e.g., IP unnumbered
interfaces).
16) To provide OVPN service that scales to a large number of
customers, no single component of the service provider networks
should be required to maintain all the information about all
the OVPNs.
Ould-Brahim, et al. July 2003 [Page 5]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
17) For scalability purposes, it SHOULD be desirable to
minimize the amount of configuration changes when
adding/deleting a port to/from a given OVPN. For the same
reasons, it is also desirable that configuration/provisioning
changes of a port to/from a given OVPN SHOULD involve
configuration/provisioning only on the device that this port is
connected to.
18) A service network SHOULD support an OVPN that spans
multiple (interconnected) service providers or multiple
networks within a single service provider.
19) For minimum disruption to the service provider existing VPN
infrastructure (e.g., layer-3 VPNs, Layer 2 VPNs), when
possible, an OVPN service SHOULD maximize reusability of
existing VPN service and technology building blocks already
deployed (e.g., management tools, membership schemes, etc.) and
being standardized in the PPVPN WG.
6.1 Service Provider Management Requirements
20) As value added OVPN services, service provider MAY provide
auto-provisioning tools to facilitate customer ordering.
(e.g. web ordering, "point-and-click" solutions). Service
provider MAY also provide its customer with customer specific
report via web access or other means.
21) Operator should have the capability to display the OVPN
topology on a per OVPN basis or multiple OVPN basis.
7. Customer Requirements
22) An OVPN customer MAY have circuits in a OVPN and "regular"
circuits on the same physical interface, or even circuits in
different OVPNs through the same physical interface.
23) The OVPN service MUST be able to support more than one link
between a given (CE, PE ONE) pair. Moreover, the service should
allow a CE to be connected to more than one PE ONE (with at
least one port per each PE ONE). And, of course, a PE ONE
should be able to have more than one CE connected to it.
24) The OVPN service SHOULD allow links from different OVPNs to
be connected to a given PE ONE. Likewise, it should allow links
from different OVPNs to be connected to a given CE.
25) The OVPN service SHOULD not require all ports on a given CE
to have the same characteristics.
Ould-Brahim, et al. July 2003 [Page 6]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
26) When a service provider network denies connectivity between
a pair of CE ports, the network MUST provide a reason (to at
least one of these CEs) for denying the connectivity.
27) The OVPN service SHOULD allow establishment of connectivity
(e.g., establishment of an optical channel trail) between a
pair of ports that belong to a given OVPN to be under control
of the customer of that OVPN. The service should provide
mechanisms to restrict such connectivity to only the ports that
belong to that particular OVPN. This connectivity could be
further restricted to only the ports with similar
characteristics.
28) The OVPN service MUST allow addressing and routing used by
the Service Provider network offering the service to be
completely independent from the addressing and routing used by
the OVPN clients of that network. Moreover, for the purpose of
the OVPN service, addressing and routing used by one OVPN
client, need not be coordinated with any other OVPN clients.
29) The OVPN service MAY assume that all the CE ports that
belong to a given VPN have identifiers that are unambiguous
within that OVPN. The service should not assume that these
identifiers are unambiguous outside of that OVPN. (As a result,
identifiers of CE ports connected to a given PE ONE may be
ambiguous).
30) The OVPN service SHOULD allow CE ports to be identified by
either network layer addresses (e.g., IPv4, IPv6, NSAP
addresses), or by a combination of CE identifier and a
port/interface index (e.g., IP unnumbered interfaces).
31) For the purpose of the OVPN service the administrative
ownership of CE ports SHOULD be orthogonal to the OVPN
membership of these ports. For example, it should be possible
to either have all CE ports within a given OVPN to be under
control of a single administration, or each port to be
controlled by its own administration.
32) The OVPN service architecture should be able to support
hierarchical VPN scenarios in which one Service Provider offers
OVPN service to another Service Provider who then resells that
OVPN service to his customers (as OVPN service or other types
of VPN service such as Layer 2 or Layer 3 VPNs)
8. Security Considerations
[TBD]
9. References
Ould-Brahim, et al. July 2003 [Page 7]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
[PPVPN-REQ] Carugi, M., et al., "Service requirements for
Provider Provisioned Virtual Private Networks", work in
progress.
[GMPLS-VPN] Ould-Brahim H., Rekhter Y., et al., "GVPN:
Generalized Provider-provisioned Port-based VPNs using BGP
and GMPLS ", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls-00.txt,
work in progress
[GMPLS-ARCH] Mannie, E., et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture", work in progress
[Framework] Rajagopalan, B. et al., "IP over Optical Networks:
A Framework ", November 2000, work in progress.
10. Acknowledgments.
The authors would like to acknowledge the following individuals
for their comments: Raymond Aubin, Erning Ye, Bryan Gleeson.
11. Author's Addresses
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
Email: hbrahim@nortelnetworks.com
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Avenue
Sunnyvale, CA 94089
Email: yakov@juniper.net
Luyuan Fang
AT&T
200 Laurel Avenue
Middletown, NJ 07748
Email: Luyuanfang@att.com
Phone: +1 (732) 420 1920
Yong Xue
UUNET/WorldCom
Ashburn, Virginia
(703)-886-5358
yxue@uu.net
Ould-Brahim, et al. July 2003 [Page 8]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
Ananth Nagarajan
Sprint
9300,Metcalf Ave
Overland Park, KS 66212
Phone +1-913-534-3973
ananth.nagarajan@mail.sprint.com
Eric Mannie
Ebone (GTS)
Terhulpsesteenweg 6A
1560 Hoeilaart
Belgium
Phone: +32 2 658 56 52
Email: eric.mannie@gts.com
Marco Carugi
France Telecom R&D
Technopole Anticipa, 2 av. P. Marzin
22307 Lannion
France
Phone : +33 2 96053617
marco.carugi@francetelecom.com
John Drake
Calient Networks
5853 Rue Ferrari
San Jose, CA 95138
USA
Phone: +1 408 972 3720
Email: jdrake@calient.net
Dimitri Papadimitriou
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Ould-Brahim, et al. July 2003 [Page 9]
draft-ouldbrahim-ppvpn-ovpn-requirements-01.txt December 2002
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implementation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
Ould-Brahim, et al. July 2003 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 14:54:29 |