Framework and Requirements for Layer 1 Virtual Private Networks
RFC 4847
| Document | Type | RFC - Informational (April 2007) | |
|---|---|---|---|
| Author | Tomonori Takeda | ||
| Last updated | 2018-12-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Ross Callon | |
| Send notices to | (None) |
RFC 4847
o PE-PE recovery
The provider network constitutes a recovery domain, and the
recovery scope is the PE-PE part of the CE-CE VPN connection.
It should be possible for the provider network to hide the provider
network recovery operation from the customer. Namely, it should be
possible to configure the provider network to not notify the
customer when a failure occurs and a PE-PE recovery operation
successfully repairs the failure. Further, when PE-PE recovery
fails and the failure should be notified to the customer, it should
be possible for the provider network to hide its internal topology.
o CE-PE recovery
The recovery scope is either or both of the ingress and egress
CE-PE links of the CE-CE VPN connection.
o CE-CE recovery
The recovery scope is the entire CE-CE VPN connection.
When a failure needs to be notified to a customer so that the
customer can initiate recovery operation, it should be possible for
the provider network to hide its internal topology.
These recovery schemes may be applied in combination.
Customers may be allowed to specify the desired recovery level in a
connection setup request. Furthermore, the customer may be allowed
to specify the desired recovery level in a way that is agnostic of
the recovery technique (e.g., when the recovery operation does not
require cooperation between the provider network and the customer
network). In such cases, the provider network must translate the
specified recovery level into specific recovery techniques, based on
operational policies. This allows enhanced recovery techniques above
and beyond the GMPLS specifications to be used in the provider
network.
9.2. Recovery Resource Sharing Schemes
The provider network may support various recovery resource sharing
schemes, such as the following:
o Shared recovery
When the provider network supports shared recovery (e.g., shared
mesh restoration [RFC4427]), the provider network may provide
Takeda Informational [Page 26]
RFC 4847 Layer 1 VPN Framework April 2007
sharing recovery resources between VPN connections that serve with
only the same VPN, a specific set of VPNs, or any VPN. The default
mode is sharing recovery resources with any VPN.
o Extra traffic
GMPLS recovery mechanisms support extra traffic. Extra traffic
allows the transfer of preemptable traffic on the recovery
resources when these resources are not being used for the recovery
of protected normal traffic [RFC4427].
In the context of L1VPNs, extra traffic is applied for CE-CE VPN
connections, or PE-PE part of CE-CE VPN connections. The latter
case may be applied only when there is hierarchy (i.e., CE-CE VPN
connection is nested on top of PE-PE connection). In this section,
the latter aspect is analyzed.
When the provider network allows a CE-CE VPN connection to be set
up as "extra traffic", it means that the VPN connection may use a
PE-PE connection that protects some other CE-CE VPN connection. In
such a case the provider network may restrict extra traffic CE-CE
VPN connection to use resources (i.e., the PE-PE connections) that:
- protect VPN connections from the same VPN as the extra traffic
connection.
- are used for a specific set of VPNs.
- are available for any VPN.
The default mode is to support preemptable traffic on recovery
resources reserved for any VPN.
10. Control Plane Connectivity
10.1. Control Plane Connectivity between a CE and a PE
In the Signaling-based service model and the Signaling and Routing
service model, there must be a control channel (IP-level
connectivity) between a CE and its PE. The instantiation of the
control channel may differ depending on addressing and security.
As stated in Section 6.1, it is necessary to disambiguate control
plane messages exchanged between the CE and PE if the CE-PE
relationship is applicable to more than one VPN. Furthermore,
private addresses may be assigned to CE-PE control channels.
Takeda Informational [Page 27]
RFC 4847 Layer 1 VPN Framework April 2007
Security aspects of the CE-PE control channel are discussed in
Section 12.
10.2. Control Plane Connectivity between CEs
A customer network connected by VPN connections may be controlled by
MPLS or GMPLS, and the VPN connections may be treated as TE links
within the customer network. In such cases, there must be control
plane (IP-level) connectivity between the CEs, so that control
messages, such as signaling and routing messages, can be exchanged
between the CEs. Furthermore, in some recovery techniques, Notify
message exchange is needed between the ingress and egress of the VPN
connection, which requires control plane connectivity between the
CEs. There are several potential ways to achieve this.
o Use of VPN connections as in-band control channels
If the CEs have the ability to inject control messages into the VPN
connections and to extract the messages at the far end of the VPN
connections, then control messages can be exchanged in-band. For
example, when a VPN connection is a Packet Switch Capable (PSC) TE
link in the customer network, this operation is transparent to the
L1VPN service provider.
o Use of overhead associated with the VPN connections
If the VPN connection provides connectivity in the customer network
at a different switching capability (implying network technology
layer) from that used by the provider network to support the CE-PE
and PE-PE connectivity, then the customer network can utilize any
overhead available within the VPN connection as a control channel
to connect the CEs. For example, if a VPN connection provides a
TDM TE link in the customer network but is supported by a
technology such as lambda or fiber, then the CEs may utilize the
overhead (DCC) as a control channel, if the network supports
transparent transfer of such overhead. This operation is
transparent to the L1VPN service provider.
o Use of control-channel-specific VPN connections
A customer establishes VPN connections dedicated as control
channels. This operation is transparent to the L1VPN service
provider, but since control plane traffic is likely to be
relatively low compared with the capacity of VPN connections, this
may be an expensive solution for the customer.
Takeda Informational [Page 28]
RFC 4847 Layer 1 VPN Framework April 2007
o Use of separate network
A customer may utilize another network and network service, such as
private line service, L3VPN service, L2VPN service, or Internet
access service, to establish CE-CE control channel connectivity.
This operation is transparent to the L1VPN service provider.
o Use of CE-PE control channels
In the Signaling-based service model, and the Signaling and Routing
service model, there must be control plane (IP-level) connectivity
between the CE and PE, as described in Section 10.1.
By utilizing this, CE-CE control message exchange could be realized
as part of the service provided by the L1VPN service provider.
Namely, the provider network transfers control messages received
over the CE-PE control channel to the other side of the provider
network and delivers them through the PE-CE control channel. The
realization of this within the provider network is up to the
operator, but where the provider network uses a GMPLS control
plane, the customer control plane messages could be forwarded
through the provider control plane, perhaps using IP tunnels.
Care must be taken to protect the provider network and other
customers from Denial of Service (DoS) attack. Traffic saturation
over the control plane network needs to be carefully managed as
well. Note that if private addresses are assigned to the CE-PE
control channels, the provider network must support VPN-scoped
routing and forwarding for control messages.
11. Manageability Considerations
Manageability considerations for GMPLS are described in existing
documents, such as [RFC3945]. Also, manageability considerations for
L3VPN are described in existing documents, such as [RFC4176]. These
manageability considerations should also be applied in L1VPNs, and
these aspects are described in this section. In addition, there are
some specific manageability considerations for L1VPNs, such as
configuration and accounting.
o Fault management
The provider network MUST support fault management. It MUST support
liveness detection, and monitoring and verification of correct
operation.
Takeda Informational [Page 29]
RFC 4847 Layer 1 VPN Framework April 2007
When a failure occurs, the provider network SHOULD correlate the
failure. Also, it SHOULD be able to detect which customer is
affected by the failure.
If the provider network can resolve failures without intervention
from the customer network, it MUST be possible to configure the
provider network to not report failures to the customers. However,
it MAY be part of an agreement between a customer and provider that
failures are reported to the customer, regardless.
o Configuration management
The provider network MUST support configuration management, such as
the following.
- Service mode/model configuration.
- Network representation configuration: Configuration of virtual
node and virtual link.
- Resource allocation configuration: Dedicated, shared. See
Section 8 for more detail.
- Recovery policy configuration: For example, recovery resource
sharing schemes, such as shared recovery, extra traffic. See
Section 9 for more detail.
- Membership configuration.
- Network/Element level configuration: For example, TE link
configuration.
It SHOULD be possible for the provider network to verify that
configuration is correctly made.
o Accounting management
The provider network MUST support accounting management. It MUST
be able to record usage of VPN connections for each customer.
o Performance management
The provider network MUST support performance management.
In particular, it MUST support performance monitoring of parameters
associated with the Service Level Agreement (SLA), such as bit
error rate per VPN connection, and SLA verification.
Takeda Informational [Page 30]
RFC 4847 Layer 1 VPN Framework April 2007
In addition, it MUST support performance monitoring and analysis of
parameters related to the network and equipment not directly
associated with the SLA, such as network resource utilization.
o Security management
The provider network MUST support security management. See Section
12 for details.
o Management systems
In order to support various management functionalities, the
provider network relies on management systems and related tools.
GMPLS protocols and potential extensions of GMPLS MUST be able to
work with management systems and related tools to provide such
functionalities.
In particular, MIB modules for GMPLS protocols and potential
extensions MUST be supported.
o Management of customer networks
Customers MAY outsource management of their network (especially CEs
and CE-CE links) to the provider network. In such case, the
provider MUST be able to manage the customer network, as well as
the provider network.
12. Security Considerations
Security is clearly one of the essential requirements in L1VPNs. In
this section, key security requirements are highlighted. Security
considerations for L3VPNs and L2VPNs are described in existing
documents, such as [RFC4110], [RFC4111], and [RFC4664]. These
security considerations should also be applied in L1VPNs, and these
aspects are described in this section. In addition, there are some
specific security considerations for L1VPNs, such as connectivity
restriction and shared control links.
This section first describes types of information to be secured.
Then, security features or aspects are described. Finally, some
considerations concerning scenarios where security mechanisms are
applied is described.
Takeda Informational [Page 31]
RFC 4847 Layer 1 VPN Framework April 2007
12.1. Types of Information
It MUST be possible to secure the information exchanged between the
customer and the provider. This includes data plane information,
control plane information, and management plane information.
At layer 1, data plane information is normally assumed to be secured
once connections are established, since those connections are
dedicated to each VPN. That is, it is not possible to communicate
unless there is a connection. Therefore, in L1VPNs, the main concern
of data plane security is restricting VPN connections to be used only
within the same VPN, as described in Section 6.2. Note that a
customer may wish to assure data plane information security against
not only other customers, but also the provider. In such case, the
customer may wish to apply their own security mechanisms for data
plane information (CE-CE security), as later described.
In addition, information contained in the provider network MUST be
secured. This includes VPN service contract information, current VPN
connection information, VPN membership information, and system
information. Note these types of information MAY be accessible to
authorized entities.
12.2. Security Features
Security features include the following:
o Data integrity
The information exchanged between the customer and the provider
MUST be delivered unchanged.
o Confidentiality
The information exchanged between the customer and the provider
MUST NOT be disclosed to a third party.
o Authentication
The entity requesting the service to the provider MUST be
identified and have its identity authenticated, and the provider
providing the service MUST also be identified and have its identify
authenticated.
Takeda Informational [Page 32]
RFC 4847 Layer 1 VPN Framework April 2007
o Access control
Access to the information contained in the provider network, which
may be information about the customer networks or the existence of
customers, as well as about the provider network, MUST be
restricted to the authorized entity.
o DoS attack detection and protection
The provider network MUST have mechanisms to detect DoS attack and
to protect against it reactively and proactively.
12.3. Scenarios
There are two scenarios (or occasions) in which security mechanisms
are applied. One is the service contract phase, where security
mechanisms are applied once. The other is the service access phase,
where security mechanisms are applied every time the service is
requested.
o Service contract scenario (static)
This scenario includes the addition of new physical devices, such
as CE devices, data links and control links. It MUST be guaranteed
that these physical devices are connected to the right entity. In
addition, authority to access specific information MAY be given to
each customer as a part of service contract.
o Service access scenario (dynamic)
This scenario includes the reception of connection requests,
routing information exchange requests (e.g., attempts to establish
a neighbor relationship in routing protocols, or command request
via the management plane interface), and management information
retrieval requests. If a communication channel between the
customer and the provider (control channel, management interface)
is physically separate per customer, and the entity connected over
this communication channel is identified in the service contract
phase, the provider can ensure who is requesting the service.
Also, the communication channel could be considered as secure.
However, when communication channel is physically shared among
customers, security mechanisms MUST be available and SHOULD be
enforced. Examples of such security mechanisms include IPsec
[RFC4302] and [RFC4303]. Note that even in the case of physically
separate communication channels, customers may wish to apply
security mechanisms to assure higher security, and such mechanisms
MUST be available.
Takeda Informational [Page 33]
RFC 4847 Layer 1 VPN Framework April 2007
When the entity requesting the service is identified, the provider
MUST ensure that the request is authorized for that entity. This
includes assuring that connection request is between VPN end points
belonging to the same VPN.
Also note that customers may wish to apply their own security
mechanisms for data plane information (CE-CE security). This
includes IPsec [RFC4302] and [RFC4303] for IP traffic.
13. Acknowledgements
The material in this document is based on the work of the ITU-T Study
Group 13.
We would like to thank Dimitri Papadimitriou, Deborah Brungard, Yakov
Rekhter, Alex Zinin, Igor Bryskin, Adrian Farrel, and Ross Callon for
their useful comments and suggestions.
Thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for
helpful input during IESG review.
14. Contributors
The foundation of this document is based heavily on the work of ITU-T
Study Group 13, Question 11. SG13/Q11 has been investigating the
service requirements and architecture for Layer 1 VPNs for some time,
and the foundation of this document is a summary and development of
the conclusions they have reached. Based on such material, the IETF
and the L1VPN WG in particular have developed this framework and
requirements for the support of L1VPNs by use of GMPLS protocols.
The details of this document are the result of contributions from
several authors who are listed here in alphabetic order. Contact
details for these authors can be found in a separate section near the
end of this document.
Raymond Aubin (Nortel)
Marco Carugi (Nortel)
Ichiro Inoue (NTT)
Hamid Ould-Brahim (Nortel)
Tomonori Takeda (NTT)
Takeda Informational [Page 34]
RFC 4847 Layer 1 VPN Framework April 2007
15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
requirements and architecture elements, ITU-T
Recommendation, September 2003, available from
<http://www.itu.int>.
16. Informative References
[Y.1313] Y.1313 - Layer 1 Virtual Private Network service and
network architectures, ITU-T Recommendation, July 2004,
available from <http://www.itu.int>.
Takeda Informational [Page 35]
RFC 4847 Layer 1 VPN Framework April 2007
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005.
[RFC4111] Fang, L., Ed., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
July 2005.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual Private
Networks (L3VPN) Operations and Management", RFC 4176,
October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-
Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)", RFC 4258,
November 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
Takeda Informational [Page 36]
RFC 4847 Layer 1 VPN Framework April 2007
Authors' Addresses
Raymond Aubin
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Canada
Phone: +1 (613) 763 2208
EMail: aubin@nortel.com
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Chateaufort
Les Jeunes Bois - MS CTF 32B5 - Chateaufort
78928 YVELINES Cedex 9 - FRANCE
Phone: +33 1 6955 7027
EMail: marco.carugi@nortel.com
Ichiro Inoue
NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 6076
EMail: inoue.ichiro@lab.ntt.co.jp
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7 Canada
Phone: +1 (613) 765 3418
EMail: hbrahim@nortel.com
Tomonori Takeda, Editor
NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan
Phone: +81 422 59 7434
EMail : takeda.tomonori@lab.ntt.co.jp
Takeda Informational [Page 37]
RFC 4847 Layer 1 VPN Framework April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Takeda Informational [Page 38]