Internet Engineering Task Force (IETF) S. Litkowski
Request for Comments: 8049 Orange Business Services
Category: Standards Track L. Tomotaki
ISSN: 2070-1721 Verizon
K. Ogaki
KDDI Corporation
February 2017
Internet Engineering Task Force (IETF) S. Litkowski
Request for Comments: 8049 Orange Business Services
Category: Standards Track L. Tomotaki
ISSN: 2070-1721 Verizon
K. Ogaki
KDDI Corporation
February 2017
YANG Data Model for L3VPN Service Delivery
L3VPN服务交付的YANG数据模型
Abstract
摘要
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
本文档定义了一个数据模型，可用于客户和网络运营商之间的通信，并提供第3层提供商提供的VPN服务。本文档仅限于RFCs 4026、4110和4364中所述的基于BGP PE的VPN。该模型旨在在管理系统上实例化，以提供整体服务。它不是直接用于网络元素的配置模型。该模型提供了第3层IP VPN服务配置组件的抽象视图。由管理系统将此模型作为输入，并使用特定的配置模型来配置不同的网络元素以提供服务。如何配置网络元素超出了本文档的范围。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8049.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8049.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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 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 Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
1.3. Tree Diagrams ..............................................5
2. Acronyms ........................................................5
3. Definitions .....................................................7
4. Layer 3 IP VPN Service Model ....................................8
5. Service Data Model Usage ........................................9
6. Design of the Data Model .......................................10
6.1. Features and Augmentation .................................18
6.2. VPN Service Overview ......................................18
6.2.1. VPN Service Topology ...............................18
6.2.1.1. Route Target Allocation ...................19
6.2.1.2. Any-to-Any ................................20
6.2.1.3. Hub and Spoke .............................20
6.2.1.4. Hub and Spoke Disjoint ....................21
6.2.2. Cloud Access .......................................22
6.2.3. Multicast Service ..................................24
6.2.4. Extranet VPNs ......................................26
6.3. Site Overview .............................................27
6.3.1. Devices and Locations ..............................29
6.3.2. Site Network Accesses ..............................30
6.3.2.1. Bearer ....................................30
6.3.2.2. Connection ................................31
6.3.2.3. Inheritance of Parameters Defined at
Site Level and Site Network Access Level ..32
6.4. Site Role .................................................32
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
1.3. Tree Diagrams ..............................................5
2. Acronyms ........................................................5
3. Definitions .....................................................7
4. Layer 3 IP VPN Service Model ....................................8
5. Service Data Model Usage ........................................9
6. Design of the Data Model .......................................10
6.1. Features and Augmentation .................................18
6.2. VPN Service Overview ......................................18
6.2.1. VPN Service Topology ...............................18
6.2.1.1. Route Target Allocation ...................19
6.2.1.2. Any-to-Any ................................20
6.2.1.3. Hub and Spoke .............................20
6.2.1.4. Hub and Spoke Disjoint ....................21
6.2.2. Cloud Access .......................................22
6.2.3. Multicast Service ..................................24
6.2.4. Extranet VPNs ......................................26
6.3. Site Overview .............................................27
6.3.1. Devices and Locations ..............................29
6.3.2. Site Network Accesses ..............................30
6.3.2.1. Bearer ....................................30
6.3.2.2. Connection ................................31
6.3.2.3. Inheritance of Parameters Defined at
Site Level and Site Network Access Level ..32
6.4. Site Role .................................................32
6.5. Site Belonging to Multiple VPNs ...........................33
6.5.1. Site VPN Flavor ....................................33
6.5.1.1. Single VPN Attachment:
site-vpn-flavor-single ....................33
6.5.1.2. MultiVPN Attachment:
site-vpn-flavor-multi .....................33
6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub ....34
6.5.1.4. NNI: site-vpn-flavor-nni ..................36
6.5.2. Attaching a Site to a VPN ..........................37
6.5.2.1. Referencing a VPN .........................37
6.5.2.2. VPN Policy ................................38
6.6. Deciding Where to Connect the Site ........................40
6.6.1. Constraint: Device .................................41
6.6.2. Constraint/Parameter: Site Location ................41
6.6.3. Constraint/Parameter: Access Type ..................42
6.6.4. Constraint: Access Diversity .......................43
6.6.5. Infeasible Access Placement ........................49
6.6.6. Examples of Access Placement .......................50
6.6.6.1. Multihoming ...............................50
6.6.6.2. Site Offload ..............................53
6.6.6.3. Parallel Links ............................59
6.6.6.4. SubVPN with Multihoming ...................60
6.6.7. Route Distinguisher and VRF Allocation .............64
6.7. Site Network Access Availability ..........................64
6.8. Traffic Protection ........................................66
6.9. Security ..................................................66
6.9.1. Authentication .....................................67
6.9.2. Encryption .........................................67
6.10. Management ...............................................68
6.11. Routing Protocols ........................................68
6.11.1. Handling of Dual Stack ............................69
6.11.2. LAN Directly Connected to SP Network ..............70
6.11.3. LAN Directly Connected to SP Network with
Redundancy ........................................70
6.11.4. Static Routing ....................................70
6.11.5. RIP Routing .......................................71
6.11.6. OSPF Routing ......................................71
6.11.7. BGP Routing .......................................73
6.12. Service ..................................................75
6.12.1. Bandwidth .........................................75
6.12.2. QoS ...............................................75
6.12.2.1. QoS Classification .......................75
6.12.2.2. QoS Profile ..............................78
6.12.3. Multicast .........................................81
6.13. Enhanced VPN Features ....................................82
6.13.1. Carriers' Carriers ................................82
6.14. External ID References ...................................83
6.5. Site Belonging to Multiple VPNs ...........................33
6.5.1. Site VPN Flavor ....................................33
6.5.1.1. Single VPN Attachment:
site-vpn-flavor-single ....................33
6.5.1.2. MultiVPN Attachment:
site-vpn-flavor-multi .....................33
6.5.1.3. SubVPN Attachment: site-vpn-flavor-sub ....34
6.5.1.4. NNI: site-vpn-flavor-nni ..................36
6.5.2. Attaching a Site to a VPN ..........................37
6.5.2.1. Referencing a VPN .........................37
6.5.2.2. VPN Policy ................................38
6.6. Deciding Where to Connect the Site ........................40
6.6.1. Constraint: Device .................................41
6.6.2. Constraint/Parameter: Site Location ................41
6.6.3. Constraint/Parameter: Access Type ..................42
6.6.4. Constraint: Access Diversity .......................43
6.6.5. Infeasible Access Placement ........................49
6.6.6. Examples of Access Placement .......................50
6.6.6.1. Multihoming ...............................50
6.6.6.2. Site Offload ..............................53
6.6.6.3. Parallel Links ............................59
6.6.6.4. SubVPN with Multihoming ...................60
6.6.7. Route Distinguisher and VRF Allocation .............64
6.7. Site Network Access Availability ..........................64
6.8. Traffic Protection ........................................66
6.9. Security ..................................................66
6.9.1. Authentication .....................................67
6.9.2. Encryption .........................................67
6.10. Management ...............................................68
6.11. Routing Protocols ........................................68
6.11.1. Handling of Dual Stack ............................69
6.11.2. LAN Directly Connected to SP Network ..............70
6.11.3. LAN Directly Connected to SP Network with
Redundancy ........................................70
6.11.4. Static Routing ....................................70
6.11.5. RIP Routing .......................................71
6.11.6. OSPF Routing ......................................71
6.11.7. BGP Routing .......................................73
6.12. Service ..................................................75
6.12.1. Bandwidth .........................................75
6.12.2. QoS ...............................................75
6.12.2.1. QoS Classification .......................75
6.12.2.2. QoS Profile ..............................78
6.12.3. Multicast .........................................81
6.13. Enhanced VPN Features ....................................82
6.13.1. Carriers' Carriers ................................82
6.14. External ID References ...................................83
6.15. Defining NNIs ............................................83
6.15.1. Defining an NNI with the Option A Flavor ..........85
6.15.2. Defining an NNI with the Option B Flavor ..........88
6.15.3. Defining an NNI with the Option C Flavor ..........91
7. Service Model Usage Example ....................................92
8. Interaction with Other YANG Modules ............................98
9. YANG Module ...................................................102
10. Security Considerations ......................................154
11. IANA Considerations ..........................................155
12. References ...................................................155
12.1. Normative References ....................................155
12.2. Informative References ..................................157
Acknowledgements .................................................157
Contributors .....................................................157
Authors' Addresses ...............................................157
6.15. Defining NNIs ............................................83
6.15.1. Defining an NNI with the Option A Flavor ..........85
6.15.2. Defining an NNI with the Option B Flavor ..........88
6.15.3. Defining an NNI with the Option C Flavor ..........91
7. Service Model Usage Example ....................................92
8. Interaction with Other YANG Modules ............................98
9. YANG Module ...................................................102
10. Security Considerations ......................................154
11. IANA Considerations ..........................................155
12. References ...................................................155
12.1. Normative References ....................................155
12.2. Informative References ..................................157
Acknowledgements .................................................157
Contributors .....................................................157
Authors' Addresses ...............................................157
This document defines a Layer 3 VPN service data model written in YANG. The model defines service configuration elements that can be used in communication protocols between customers and network operators. Those elements can also be used as input to automated control and configuration applications.
本文档定义了一个用YANG编写的第3层VPN服务数据模型。该模型定义了可用于客户和网络运营商之间通信协议的服务配置元素。这些元素也可以用作自动控制和配置应用程序的输入。
The following terms are defined in [RFC6241] and are not redefined here:
[RFC6241]中定义了以下术语，此处未重新定义：
o client
o 客户
o configuration data
o 配置数据
o server
o 服务器
o state data
o 状态数据
The following terms are defined in [RFC7950] and are not redefined here:
[RFC7950]中定义了以下术语，此处未重新定义：
o augment
o 加强
o data model
o 数据模型
o data node
o 数据节点
The terminology for describing YANG data models is found in [RFC7950].
描述YANG数据模型的术语见[RFC7950]。
This document presents some configuration examples using XML representation.
本文档介绍了一些使用XML表示的配置示例。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A simplified graphical representation of the data model is presented in Section 6.
第6节给出了数据模型的简化图形表示。
The meanings of the symbols in these diagrams are as follows:
这些图表中的符号含义如下：
o Brackets "[" and "]" enclose list keys.
o 括号“[”和“]”包含列表键。
o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional.
o 大括号“{”和“}”包含使相应节点具有条件的可选功能的名称。
o Abbreviations before data node names: "rw" means configuration data (read-write), and "ro" means state data (read-only).
o 数据节点名称前的缩写：“rw”表示配置数据（读写），“ro”表示状态数据（只读）。
o Symbols after data node names: "?" means an optional node, and "*" denotes a "list" or "leaf-list".
o 数据节点名称后的符号：“？”表示可选节点，“*”表示“列表”或“叶列表”。
o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":").
o 括号括住选项和事例节点，事例节点也用冒号（“：”）标记。
o Ellipsis ("...") stands for contents of subtrees that are not shown.
o 省略号（“…”）表示未显示的子树的内容。
AAA: Authentication, Authorization, and Accounting.
AAA：身份验证、授权和记帐。
ACL: Access Control List.
ACL：访问控制列表。
ADSL: Asymmetric DSL.
ADSL：不对称DSL。
AH: Authentication Header.
认证头。
AS: Autonomous System.
AS：自治系统。
ASBR: Autonomous System Border Router.
ASBR：自治系统边界路由器。
ASM: Any-Source Multicast.
ASM：任何源多播。
BAS: Broadband Access Switch.
宽带接入交换机。
BFD: Bidirectional Forwarding Detection.
双向转发检测。
BGP: Border Gateway Protocol.
边界网关协议。
BSR: Bootstrap Router.
引导路由器。
CE: Customer Edge.
行政长官：客户优势。
CLI: Command Line Interface.
CLI：命令行界面。
CsC: Carriers' Carriers.
CsC：承运人的承运人。
CSP: Cloud Service Provider.
云服务提供商。
DHCP: Dynamic Host Configuration Protocol.
DHCP：动态主机配置协议。
DSLAM: Digital Subscriber Line Access Multiplexer.
DSLAM：数字用户线接入多路复用器。
ESP: Encapsulating Security Payload.
ESP：封装安全有效负载。
GRE: Generic Routing Encapsulation.
GRE：通用路由封装。
IGMP: Internet Group Management Protocol.
IGMP：Internet组管理协议。
LAN: Local Area Network.
局域网：局域网。
MLD: Multicast Listener Discovery.
MLD：多播侦听器发现。
MTU: Maximum Transmission Unit.
MTU：最大传输单位。
NAT: Network Address Translation.
NAT：网络地址转换。
NETCONF: Network Configuration Protocol.
NETCONF：网络配置协议。
NNI: Network-to-Network Interface.
NNI：网络到网络接口。
OAM: Operations, Administration, and Maintenance.
OAM：运营、管理和维护。
OSPF: Open Shortest Path First.
OSPF：首先打开最短路径。
OSS: Operations Support System.
操作支持系统。
PE: Provider Edge.
PE：提供者边缘。
PIM: Protocol Independent Multicast.
PIM：独立于协议的多播。
POP: Point of Presence.
流行音乐：存在点。
QoS: Quality of Service.
QoS：服务质量。
RD: Route Distinguisher.
道路识别器。
RIP: Routing Information Protocol.
路由信息协议。
RP: Rendezvous Point.
交会点。
RT: Route Target.
路线目标。
SFTP: Secure FTP.
安全FTP。
SLA: Service Level Agreement.
SLA：服务级别协议。
SLAAC: Stateless Address Autoconfiguration.
SLAAC：无状态地址自动配置。
SP: Service Provider.
SP：服务提供商。
SPT: Shortest Path Tree.
最短路径树。
SSM: Source-Specific Multicast.
SSM：特定于源的多播。
VM: Virtual Machine.
虚拟机：虚拟机。
VPN: Virtual Private Network.
VPN：虚拟专用网络。
VRF: VPN Routing and Forwarding.
VRF:VPN路由和转发。
VRRP: Virtual Router Redundancy Protocol.
虚拟路由器冗余协议。
Customer Edge (CE) Device: A CE is equipment dedicated to a particular customer; it is directly connected (at Layer 3) to one or more PE devices via attachment circuits. A CE is usually located at the customer premises and is usually dedicated to a single VPN, although it may support multiple VPNs if each one has separate attachment circuits.
客户边缘（CE）设备：CE是专用于特定客户的设备；它通过连接电路直接连接（在第3层）到一个或多个PE设备。CE通常位于客户场所，通常专用于单个VPN，但如果每个VPN都有单独的连接电路，则可能支持多个VPN。
Provider Edge (PE) Device: A PE is equipment managed by the SP; it can support multiple VPNs for different customers and is directly connected (at Layer 3) to one or more CE devices via attachment circuits. A PE is usually located at an SP point of presence (POP) and is managed by the SP.
提供商边缘（PE）设备：PE是SP管理的设备；它可以为不同的客户支持多个VPN，并通过连接电路直接连接（在第3层）到一个或多个CE设备。PE通常位于SP存在点（POP），由SP管理。
PE-Based VPNs: The PE devices know that certain traffic is VPN traffic. They forward the traffic (through tunnels) based on the destination IP address of the packet and, optionally, based on other information in the IP header of the packet. The PE devices are themselves the tunnel endpoints. The tunnels may make use of various encapsulations to send traffic over the SP network (such as, but not restricted to, GRE, IP-in-IP, IPsec, or MPLS tunnels).
基于PE的VPN：PE设备知道某些流量是VPN流量。它们根据数据包的目的地IP地址和数据包的IP报头中的其他信息（可选）转发流量（通过隧道）。PE设备本身就是隧道端点。隧道可利用各种封装在SP网络上发送通信量（例如但不限于GRE、IP中的IP、IPsec或MPLS隧道）。
A Layer 3 IP VPN service is a collection of sites that are authorized to exchange traffic between each other over a shared IP infrastructure. This Layer 3 VPN service model aims at providing a common understanding of how the corresponding IP VPN service is to be deployed over the shared infrastructure. This service model is limited to BGP PE-based VPNs as described in [RFC4026], [RFC4110], and [RFC4364].
第3层IP VPN服务是授权通过共享IP基础设施在彼此之间交换流量的站点集合。此第3层VPN服务模型旨在提供有关如何在共享基础设施上部署相应IP VPN服务的共识。此服务模型仅限于[RFC4026]、[RFC4110]和[RFC4364]中所述的基于BGP PE的VPN。
l3vpn-svc |
Model |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| NETCONF/CLI ...
| |
+------------------------------------------------+
Network
l3vpn-svc |
Model |
|
+------------------+ +-----+
| Orchestration | < --- > | OSS |
+------------------+ +-----+
| |
+----------------+ |
| Config manager | |
+----------------+ |
| |
| NETCONF/CLI ...
| |
+------------------------------------------------+
Network
+++++++
+ AAA +
+++++++
+++++++
+ AAA +
+++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
++++++++ Bearer ++++++++ ++++++++ ++++++++
+ CE A + ----------- + PE A + + PE B + ---- + CE B +
++++++++ Connection ++++++++ ++++++++ ++++++++
Site A Site B
场地A场地B
The idea of the L3 IP VPN service model is to propose an abstracted interface between customers and network operators to manage configuration of components of an L3VPN service. A typical scenario would be to use this model as an input for an orchestration layer that will be responsible for translating it to an orchestrated configuration of network elements that will be part of the service. The network elements can be routers but can also be servers (like AAA); the network's configuration is not limited to these examples. The configuration of network elements can be done via the CLI, NETCONF/RESTCONF [RFC6241] [RFC8040] coupled with YANG data models of a specific configuration (BGP, VRF, BFD, etc.), or some other technique, as preferred by the operator.
L3 IP VPN服务模型的思想是在客户和网络运营商之间提出一个抽象接口，以管理L3VPN服务组件的配置。典型的场景是使用此模型作为编排层的输入，编排层负责将其转换为作为服务一部分的网络元素的编排配置。网络元件可以是路由器，也可以是服务器（如AAA）；网络的配置不限于这些示例。网元的配置可以通过CLI、NETCONF/RESTCONF[RFC6241][RFC8040]以及特定配置的数据模型（BGP、VRF、BFD等）或操作员首选的其他技术完成。
The usage of this service model is not limited to this example; it can be used by any component of the management system but not directly by network elements.
此服务模型的使用不限于此示例；它可以由管理系统的任何组件使用，但不能直接由网络元素使用。
The YANG module is divided into two main containers: "vpn-services" and "sites".
YANG模块分为两个主要容器：“vpn服务”和“站点”。
The "vpn-service" list under the vpn-services container defines global parameters for the VPN service for a specific customer.
vpn服务容器下的“vpn服务”列表定义特定客户的vpn服务的全局参数。
A "site" is composed of at least one "site-network-access" and, in the case of multihoming, may have multiple site-network-access points. The site-network-access attachment is done through a "bearer" with an "ip-connection" on top. The bearer refers to properties of the attachment that are below Layer 3, while the connection refers to properties oriented to the Layer 3 protocol. The bearer may be allocated dynamically by the SP, and the customer may provide some constraints or parameters to drive the placement of the access.
“站点”由至少一个“站点网络接入”组成，并且在多主的情况下，可以具有多个站点网络接入点。站点网络访问连接通过顶部带有“ip连接”的“承载器”完成。承载指的是第3层之下的附件属性，而连接指的是面向第3层协议的属性。承载可以由SP动态地分配，并且客户可以提供一些约束或参数来驱动接入的放置。
Authorization of traffic exchange is done through what we call a VPN policy or VPN service topology defining routing exchange rules between sites.
流量交换的授权是通过定义站点间路由交换规则的VPN策略或VPN服务拓扑来完成的。
The figure below describes the overall structure of the YANG module:
下图描述了YANG模块的整体结构：
module: ietf-l3vpn-svc
+--rw l3vpn-svc
+--rw vpn-services
| +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id
| +--rw customer-name? string
| +--rw vpn-service-topology? identityref
| +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier string
| | +--rw (list-flavor)?
| | | +--:(permit-any)
| | | | +--rw permit-any? empty
| | | +--:(deny-any-except)
| | | | +--rw permit-site* leafref
| | | +--:(permit-any-except)
| | | +--rw deny-site* leafref
| | +--rw authorized-sites
| | | +--rw authorized-site* [site-id]
| | | +--rw site-id leafref
| | +--rw denied-sites
| | | +--rw denied-site* [site-id]
| | | +--rw site-id leafref
| | +--rw address-translation
module: ietf-l3vpn-svc
+--rw l3vpn-svc
+--rw vpn-services
| +--rw vpn-service* [vpn-id]
| +--rw vpn-id svc-id
| +--rw customer-name? string
| +--rw vpn-service-topology? identityref
| +--rw cloud-accesses {cloud-access}?
| | +--rw cloud-access* [cloud-identifier]
| | +--rw cloud-identifier string
| | +--rw (list-flavor)?
| | | +--:(permit-any)
| | | | +--rw permit-any? empty
| | | +--:(deny-any-except)
| | | | +--rw permit-site* leafref
| | | +--:(permit-any-except)
| | | +--rw deny-site* leafref
| | +--rw authorized-sites
| | | +--rw authorized-site* [site-id]
| | | +--rw site-id leafref
| | +--rw denied-sites
| | | +--rw denied-site* [site-id]
| | | +--rw site-id leafref
| | +--rw address-translation
| | +--rw nat44
| | +--rw enabled? boolean
| | +--rw nat44-customer-address? inet:ipv4-address
| +--rw multicast {multicast}?
| | +--rw enabled? boolean
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw rp
| | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16
| | | +--rw provider-managed
| | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean
| | | +--rw rp-address? inet:ip-address
| | | +--rw groups
| | | +--rw group* [id]
| | | +--rw id uint16
| | | +--rw (group-format)?
| | | +--:(startend)
| | | | +--rw group-start? inet:ip-address
| | | | +--rw group-end? inet:ip-address
| | | +--:(singleaddress)
| | | +--rw group-address? inet:ip-address
| | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address
| +--rw carrierscarrier? boolean {carrierscarrier}?
| +--rw extranet-vpns {extranet-vpn}?
| +--rw extranet-vpn* [vpn-id]
| +--rw vpn-id svc-id
| +--rw local-sites-role? identityref
+--rw sites
+--rw site* [site-id]
+--rw site-id svc-id
+--rw requested-site-start? yang:date-and-time
+--rw requested-site-stop? yang:date-and-time
+--rw locations
| +--rw location* [location-id]
| +--rw location-id svc-id
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
| | +--rw nat44
| | +--rw enabled? boolean
| | +--rw nat44-customer-address? inet:ipv4-address
| +--rw multicast {multicast}?
| | +--rw enabled? boolean
| | +--rw customer-tree-flavors
| | | +--rw tree-flavor* identityref
| | +--rw rp
| | +--rw rp-group-mappings
| | | +--rw rp-group-mapping* [id]
| | | +--rw id uint16
| | | +--rw provider-managed
| | | | +--rw enabled? boolean
| | | | +--rw rp-redundancy? boolean
| | | | +--rw optimal-traffic-delivery? boolean
| | | +--rw rp-address? inet:ip-address
| | | +--rw groups
| | | +--rw group* [id]
| | | +--rw id uint16
| | | +--rw (group-format)?
| | | +--:(startend)
| | | | +--rw group-start? inet:ip-address
| | | | +--rw group-end? inet:ip-address
| | | +--:(singleaddress)
| | | +--rw group-address? inet:ip-address
| | +--rw rp-discovery
| | +--rw rp-discovery-type? identityref
| | +--rw bsr-candidates
| | +--rw bsr-candidate-address* inet:ip-address
| +--rw carrierscarrier? boolean {carrierscarrier}?
| +--rw extranet-vpns {extranet-vpn}?
| +--rw extranet-vpn* [vpn-id]
| +--rw vpn-id svc-id
| +--rw local-sites-role? identityref
+--rw sites
+--rw site* [site-id]
+--rw site-id svc-id
+--rw requested-site-start? yang:date-and-time
+--rw requested-site-stop? yang:date-and-time
+--rw locations
| +--rw location* [location-id]
| +--rw location-id svc-id
| +--rw address? string
| +--rw postal-code? string
| +--rw state? string
| +--rw city? string
| +--rw country-code? string
+--rw devices
| +--rw device* [device-id]
| +--rw device-id svc-id
| +--rw location? leafref
| +--rw management
| +--rw address-family? address-family
| +--rw address? inet:ip-address
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw management
| +--rw type? identityref
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id svc-id
| +--rw entries* [id]
| +--rw id svc-id
| +--rw filter
| | +--rw (lan)?
| | +--:(prefixes)
| | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}?
| | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}?
| | +--:(lan-tag)
| | +--rw lan-tag* string
| +--rw vpn
| +--rw vpn-id leafref
| +--rw site-role? identityref
+--rw site-vpn-flavor? identityref
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af address-family
| +--rw maximum-routes? uint32
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? string
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| | +--rw preshared-key? string
| +--:(pki)
+--rw devices
| +--rw device* [device-id]
| +--rw device-id svc-id
| +--rw location? leafref
| +--rw management
| +--rw address-family? address-family
| +--rw address? inet:ip-address
+--rw site-diversity {site-diversity}?
| +--rw groups
| +--rw group* [group-id]
| +--rw group-id string
+--rw management
| +--rw type? identityref
+--rw vpn-policies
| +--rw vpn-policy* [vpn-policy-id]
| +--rw vpn-policy-id svc-id
| +--rw entries* [id]
| +--rw id svc-id
| +--rw filter
| | +--rw (lan)?
| | +--:(prefixes)
| | | +--rw ipv4-lan-prefix* inet:ipv4-prefix {ipv4}?
| | | +--rw ipv6-lan-prefix* inet:ipv6-prefix {ipv6}?
| | +--:(lan-tag)
| | +--rw lan-tag* string
| +--rw vpn
| +--rw vpn-id leafref
| +--rw site-role? identityref
+--rw site-vpn-flavor? identityref
+--rw maximum-routes
| +--rw address-family* [af]
| +--rw af address-family
| +--rw maximum-routes? uint32
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? string
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| | +--rw preshared-key? string
| +--:(pki)
+--rw service
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id uint16
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1p? uint8
| | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
| | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
| | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
| | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
| | | | | +--rw l4-src-port? inet:port-number
| | | | | +--rw target-sites* svc-id
| | | | | +--rw l4-src-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw l4-dst-port? inet:port-number
| | | | | +--rw l4-dst-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw protocol-field? union
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? string
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw rate-limit? uint8
| | +--rw latency
| | | +--rw (flavor)?
| | | ...
| | +--rw jitter
| | | +--rw (flavor)?
| | | ...
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent? uint8
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
+--rw service
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id uint16
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | +--rw dscp? inet:dscp
| | | | | +--rw dot1p? uint8
| | | | | +--rw ipv4-src-prefix? inet:ipv4-prefix
| | | | | +--rw ipv6-src-prefix? inet:ipv6-prefix
| | | | | +--rw ipv4-dst-prefix? inet:ipv4-prefix
| | | | | +--rw ipv6-dst-prefix? inet:ipv6-prefix
| | | | | +--rw l4-src-port? inet:port-number
| | | | | +--rw target-sites* svc-id
| | | | | +--rw l4-src-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw l4-dst-port? inet:port-number
| | | | | +--rw l4-dst-port-range
| | | | | | +--rw lower-port? inet:port-number
| | | | | | +--rw upper-port? inet:port-number
| | | | | +--rw protocol-field? union
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? string
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | +--rw class-id string
| | +--rw rate-limit? uint8
| | +--rw latency
| | | +--rw (flavor)?
| | | ...
| | +--rw jitter
| | | +--rw (flavor)?
| | | ...
| | +--rw bandwidth
| | +--rw guaranteed-bw-percent? uint8
| | +--rw end-to-end? empty
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw traffic-protection {fast-reroute}?
| +--rw enabled? boolean
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address? yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system? uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw site-network-accesses
+--rw site-network-access* [site-network-access-id]
+--rw site-network-access-id svc-id
+--rw site-network-access-type? identityref
+--rw (location-flavor)
| +--:(location)
| | +--rw location-reference? leafref
| +--:(device)
| +--rw device-reference? leafref
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw traffic-protection {fast-reroute}?
| +--rw enabled? boolean
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address? yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system? uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--ro actual-site-start? yang:date-and-time
+--ro actual-site-stop? yang:date-and-time
+--rw site-network-accesses
+--rw site-network-access* [site-network-access-id]
+--rw site-network-access-id svc-id
+--rw site-network-access-type? identityref
+--rw (location-flavor)
| +--:(location)
| | +--rw location-reference? leafref
| +--:(device)
| +--rw device-reference? leafref
+--rw access-diversity {site-diversity}?
| +--rw groups
| | +--rw group* [group-id]
| | +--rw group-id string
| +--rw constraints
| +--rw constraint* [constraint-type]
| +--rw constraint-type identityref
| +--rw target
| +--rw (target-flavor)?
| +--:(id)
| | +--rw group* [group-id]
| | ...
| +--:(all-accesses)
| | +--rw all-other-accesses? empty
| +--:(all-groups)
| +--rw all-other-groups? empty
+--rw bearer
| +--rw requested-type {requested-type}?
| | +--rw requested-type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string {bearer-reference}?
+--rw ip-connection
| +--rw ipv4 {ipv4}?
| | +--rw address-allocation-type? identityref
| | +--rw number-of-dynamic-address? uint8
| | +--rw dhcp-relay
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv4-address
| | +--rw addresses
| | +--rw provider-address? inet:ipv4-address
| | +--rw customer-address? inet:ipv4-address
| | +--rw mask? uint8
| +--rw ipv6 {ipv6}?
| | +--rw address-allocation-type? identityref
| | +--rw number-of-dynamic-address? uint8
| | +--rw dhcp-relay
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv6-address
| | +--rw addresses
| | +--rw provider-address? inet:ipv6-address
| | +--rw customer-address? inet:ipv6-address
| | +--rw mask? uint8
+--rw access-diversity {site-diversity}?
| +--rw groups
| | +--rw group* [group-id]
| | +--rw group-id string
| +--rw constraints
| +--rw constraint* [constraint-type]
| +--rw constraint-type identityref
| +--rw target
| +--rw (target-flavor)?
| +--:(id)
| | +--rw group* [group-id]
| | ...
| +--:(all-accesses)
| | +--rw all-other-accesses? empty
| +--:(all-groups)
| +--rw all-other-groups? empty
+--rw bearer
| +--rw requested-type {requested-type}?
| | +--rw requested-type? string
| | +--rw strict? boolean
| +--rw always-on? boolean {always-on}?
| +--rw bearer-reference? string {bearer-reference}?
+--rw ip-connection
| +--rw ipv4 {ipv4}?
| | +--rw address-allocation-type? identityref
| | +--rw number-of-dynamic-address? uint8
| | +--rw dhcp-relay
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv4-address
| | +--rw addresses
| | +--rw provider-address? inet:ipv4-address
| | +--rw customer-address? inet:ipv4-address
| | +--rw mask? uint8
| +--rw ipv6 {ipv6}?
| | +--rw address-allocation-type? identityref
| | +--rw number-of-dynamic-address? uint8
| | +--rw dhcp-relay
| | | +--rw customer-dhcp-servers
| | | +--rw server-ip-address* inet:ipv6-address
| | +--rw addresses
| | +--rw provider-address? inet:ipv6-address
| | +--rw customer-address? inet:ipv6-address
| | +--rw mask? uint8
| +--rw oam
| +--rw bfd {bfd}?
| +--rw enabled? boolean
| +--rw (holdtime)?
| +--:(profile)
| | +--rw profile-name? string
| +--:(fixed)
| +--rw fixed-value? uint32
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? string
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| | ...
| +--:(pki)
+--rw service
| +--rw svc-input-bandwidth? uint32
| +--rw svc-output-bandwidth? uint32
| +--rw svc-mtu? uint16
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id uint16
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | ...
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? string
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | ...
| +--rw oam
| +--rw bfd {bfd}?
| +--rw enabled? boolean
| +--rw (holdtime)?
| +--:(profile)
| | +--rw profile-name? string
| +--:(fixed)
| +--rw fixed-value? uint32
+--rw security
| +--rw authentication
| +--rw encryption {encryption}?
| +--rw enabled? boolean
| +--rw layer enumeration
| +--rw encryption-profile
| +--rw (profile)?
| +--:(provider-profile)
| | +--rw profile-name? string
| +--:(customer-profile)
| +--rw algorithm? string
| +--rw (key-type)?
| +--:(psk)
| | ...
| +--:(pki)
+--rw service
| +--rw svc-input-bandwidth? uint32
| +--rw svc-output-bandwidth? uint32
| +--rw svc-mtu? uint16
| +--rw qos {qos}?
| | +--rw qos-classification-policy
| | | +--rw rule* [id]
| | | +--rw id uint16
| | | +--rw (match-type)?
| | | | +--:(match-flow)
| | | | | +--rw match-flow
| | | | | ...
| | | | +--:(match-application)
| | | | +--rw match-application? identityref
| | | +--rw target-class-id? string
| | +--rw qos-profile
| | +--rw (qos-profile)?
| | +--:(standard)
| | | +--rw profile? string
| | +--:(custom)
| | +--rw classes {qos-custom}?
| | +--rw class* [class-id]
| | ...
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address? yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system? uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--rw availability
| +--rw access-priority? uint32
+--rw vpn-attachment
+--rw (attachment-flavor)
+--:(vpn-policy-id)
| +--rw vpn-policy-id? leafref
+--:(vpn-id)
+--rw vpn-id? leafref
+--rw site-role? identityref
| +--rw carrierscarrier {carrierscarrier}?
| | +--rw signalling-type? enumeration
| +--rw multicast {multicast}?
| +--rw multicast-site-type? enumeration
| +--rw multicast-address-family
| | +--rw ipv4? boolean {ipv4}?
| | +--rw ipv6? boolean {ipv6}?
| +--rw protocol-type? enumeration
+--rw routing-protocols
| +--rw routing-protocol* [type]
| +--rw type identityref
| +--rw ospf {rtg-ospf}?
| | +--rw address-family* address-family
| | +--rw area-address? yang:dotted-quad
| | +--rw metric? uint16
| | +--rw sham-links {rtg-ospf-sham-link}?
| | +--rw sham-link* [target-site]
| | +--rw target-site svc-id
| | +--rw metric? uint16
| +--rw bgp {rtg-bgp}?
| | +--rw autonomous-system? uint32
| | +--rw address-family* address-family
| +--rw static
| | +--rw cascaded-lan-prefixes
| | +--rw ipv4-lan-prefixes* [lan next-hop] {ipv4}?
| | | +--rw lan inet:ipv4-prefix
| | | +--rw lan-tag? string
| | | +--rw next-hop inet:ipv4-address
| | +--rw ipv6-lan-prefixes* [lan next-hop] {ipv6}?
| | +--rw lan inet:ipv6-prefix
| | +--rw lan-tag? string
| | +--rw next-hop inet:ipv6-address
| +--rw rip {rtg-rip}?
| | +--rw address-family* address-family
| +--rw vrrp {rtg-vrrp}?
| +--rw address-family* address-family
+--rw availability
| +--rw access-priority? uint32
+--rw vpn-attachment
+--rw (attachment-flavor)
+--:(vpn-policy-id)
| +--rw vpn-policy-id? leafref
+--:(vpn-id)
+--rw vpn-id? leafref
+--rw site-role? identityref
The model defined in this document implements many features that allow implementations to be modular. As an example, an implementation may support only IPv4 VPNs (IPv4 feature), IPv6 VPNs (IPv6 feature), or both (by advertising both features). The routing protocols proposed to the customer may also be enabled through features. This model also proposes some features for options that are more advanced, such as support for extranet VPNs (Section 6.2.4), site diversity (Section 6.6), and QoS (Section 6.12.2).
本文档中定义的模型实现了许多允许实现模块化的特性。例如，实现可能仅支持IPv4 VPN（IPv4功能）、IPv6 VPN（IPv6功能）或两者（通过公布这两种功能）。建议给客户的路由协议也可以通过功能启用。该模型还为更高级的选项提供了一些功能，例如支持外部网络VPN（第6.2.4节）、站点多样性（第6.6节）和QoS（第6.12.2节）。
In addition, as for any YANG model, this service model can be augmented to implement new behaviors or specific features. For example, this model proposes different options for IP address assignments; if those options do not fulfill all requirements, new options can be added through augmentation.
此外，对于任何YANG模型，此服务模型都可以扩展以实现新的行为或特定功能。例如，该模型提出了不同的IP地址分配选项；如果这些选项不能满足所有要求，可以通过扩充添加新选项。
A vpn-service list item contains generic information about the VPN service. The "vpn-id" provided in the vpn-service list refers to an internal reference for this VPN service, while the customer name refers to a more-explicit reference to the customer. This identifier is purely internal to the organization responsible for the VPN service.
vpn服务列表项包含有关vpn服务的常规信息。vpn服务列表中提供的“vpn id”指的是此vpn服务的内部引用，而客户名称指的是对客户的更明确引用。此标识符纯粹是负责VPN服务的组织的内部标识符。
The type of VPN service topology is required for configuration. Our proposed model supports any-to-any, Hub and Spoke (where Hubs can exchange traffic), and "Hub and Spoke disjoint" (where Hubs cannot exchange traffic). New topologies could be added via augmentation. By default, the any-to-any VPN service topology is used.
配置需要VPN服务拓扑的类型。我们提出的模型支持任意对任意、中心辐射（中心可以交换流量）和“中心辐射不相交”（中心不能交换流量）。可以通过扩充来添加新拓扑。默认情况下，使用任意到任意VPN服务拓扑。
A Layer 3 PE-based VPN is built using route targets (RTs) as described in [RFC4364]. The management system is expected to automatically allocate a set of RTs upon receiving a VPN service creation request. How the management system allocates RTs is out of scope for this document, but multiple ways could be envisaged, as described below.
如[RFC4364]所述，使用路由目标（RTs）构建基于第3层PE的VPN。管理系统在收到VPN服务创建请求时，应自动分配一组RTs。管理系统如何分配RTs超出了本文件的范围，但可以设想多种方式，如下所述。
Management system
<------------------------------------------------->
Request RT
+-----------------------+ Topo a2a +----------+
RESTCONF | | -----> | |
User ------------- | Service Orchestration | | Network |
l3vpn-svc | | <----- | OSS |
Model +-----------------------+ Response +----------+
RT1, RT2
Management system
<------------------------------------------------->
Request RT
+-----------------------+ Topo a2a +----------+
RESTCONF | | -----> | |
User ------------- | Service Orchestration | | Network |
l3vpn-svc | | <----- | OSS |
Model +-----------------------+ Response +----------+
RT1, RT2
In the example above, a service orchestration, owning the instantiation of this service model, requests RTs to the network OSS. Based on the requested VPN service topology, the network OSS replies with one or multiple RTs. The interface between this service orchestration and the network OSS is out of scope for this document.
在上面的示例中，拥有此服务模型实例化的服务编排向网络OSS请求RTs。根据请求的VPN服务拓扑，网络OSS使用一个或多个RTs进行响应。此服务编排与网络OSS之间的接口超出了本文档的范围。
+---------------------------+
RESTCONF | |
User ------------- | Service Orchestration |
l3vpn-svc | |
Model | |
| RT pool: 10:1->10:10000 |
| RT pool: 20:50->20:5000 |
+---------------------------+
+---------------------------+
RESTCONF | |
User ------------- | Service Orchestration |
l3vpn-svc | |
Model | |
| RT pool: 10:1->10:10000 |
| RT pool: 20:50->20:5000 |
+---------------------------+
In the example above, a service orchestration, owning the instantiation of this service model, owns one or more pools of RTs (specified by the SP) that can be allocated. Based on the requested VPN service topology, it will allocate one or multiple RTs from the pool.
在上面的示例中，拥有此服务模型实例化的服务编排拥有一个或多个可分配的RTs池（由SP指定）。根据请求的VPN服务拓扑，它将从池中分配一个或多个RTs。
The mechanisms shown above are just examples and should not be considered an exhaustive list of solutions.
以上所示的机制只是示例，不应被视为解决方案的详尽列表。
+------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+
+------------------------------------------------------------+
| VPN1_Site1 ------ PE1 PE2 ------ VPN1_Site2 |
| |
| VPN1_Site3 ------ PE3 PE4 ------ VPN1_Site4 |
+------------------------------------------------------------+
Any-to-Any VPN Service Topology
任意到任意VPN服务拓扑
In the any-to-any VPN service topology, all VPN sites can communicate with each other without any restrictions. The management system that receives an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. In the any-to-any case, a single RT is generally required, and every VRF imports and exports this RT.
在任意对任意VPN服务拓扑中，所有VPN站点都可以不受任何限制地相互通信。通过此模型接收任意对任意IP VPN服务请求的管理系统预计将在适当的PE上分配并配置VRF和RTs。在任意情况下，通常需要一个RT，每个VRF导入和导出此RT。
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+
| |
| +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
| +----------------------------------+
| |
| +----------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub-and-Spoke VPN Service Topology
中心辐射式VPN服务拓扑
In the Hub-and-Spoke VPN service topology, all Spoke sites can communicate only with Hub sites but not with each other, and Hubs can also communicate with each other. The management system that owns an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. In the Hub-and-Spoke case, two RTs are generally required (one RT for Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub sites will export Hub routes with the Hub RT and will import Spoke routes through the Spoke RT. It will also import the Hub RT to allow Hub-to-Hub communication. A Spoke VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT.
在集线器和分支VPN服务拓扑中，所有分支站点只能与集线器站点通信，而不能相互通信，集线器也可以相互通信。通过此模型拥有任意对任意IP VPN服务请求的管理系统预计将在适当的PE上分配并配置VRF和RTs。在集线器和辐条的情况下，通常需要两个RT（一个RT用于集线器路由，一个RT用于辐条路由）。连接集线器站点的集线器VRF将使用集线器RT导出集线器路由，并通过分支RT导入分支路由。它还将导入集线器RT以允许集线器到集线器的通信。连接分支站点的分支VRF将使用分支RT导出分支路由，并通过集线器RT导入集线器路由。
The management system MUST take into account constraints on Hub-and-Spoke connections. For example, if a management system decides to mesh a Spoke site and a Hub site on the same PE, it needs to mesh connections in different VRFs, as shown in the figure below.
管理系统必须考虑轮毂和轮辐连接的约束。例如，如果管理系统决定在同一个PE上对分支站点和中心站点进行网格化，则需要在不同的VRF中对连接进行网格化，如下图所示。
Hub_Site ------- (VRF_Hub) PE1
(VRF_Spoke)
/ |
Spoke_Site1 -------------------+ |
|
Spoke_Site2 -----------------------+
Hub_Site ------- (VRF_Hub) PE1
(VRF_Spoke)
/ |
Spoke_Site1 -------------------+ |
|
Spoke_Site2 -----------------------+
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+
| |
+--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| Hub_Site1 ------ PE1 PE2 ------ Spoke_Site1 |
+--------------------------+ +-------------------------------+
| |
+--------------------------+ +-------------------------------+
| Hub_Site2 ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
Hub and Spoke Disjoint VPN Service Topology
中心辐射不相交VPN服务拓扑
In the Hub and Spoke disjoint VPN service topology, all Spoke sites can communicate only with Hub sites but not with each other, and Hubs cannot communicate with each other. The management system that owns an any-to-any IP VPN service request through this model is expected to assign and then configure the VRF and RTs on the appropriate PEs. In the Hub-and-Spoke case, two RTs are required (one RT for Hub routes and one RT for Spoke routes). A Hub VRF that connects Hub sites will export Hub routes with the Hub RT and will import Spoke routes through the Spoke RT. A Spoke VRF that connects Spoke sites will export Spoke routes with the Spoke RT and will import Hub routes through the Hub RT.
在集线器和分支不相交的VPN服务拓扑中，所有分支站点只能与集线器站点通信，而不能相互通信，集线器不能相互通信。通过此模型拥有任意对任意IP VPN服务请求的管理系统预计将在适当的PE上分配并配置VRF和RTs。在集线器和辐条的情况下，需要两个RT（一个RT用于集线器路由，一个RT用于辐条路由）。连接集线器站点的集线器VRF将使用集线器RT导出集线器路由，并通过分支RT导入分支路由。连接分支站点的分支VRF将使用分支RT导出分支路由，并通过集线器RT导入集线器路由。
The management system MUST take into account constraints on Hub-and-Spoke connections, as in the previous case.
管理系统必须考虑轮毂和轮辐连接的约束，如前一种情况。
Hub and Spoke disjoint can also be seen as multiple Hub-and-Spoke VPNs (one per Hub) that share a common set of Spoke sites.
中心辐射不相交也可以看作是共享一组公共辐射站点的多个中心辐射VPN（每个中心一个）。
The proposed model provides cloud access configuration via the "cloud-accesses" container. The usage of cloud-access is targeted for the public cloud. An Internet access can also be considered a public cloud access service. The cloud-accesses container provides parameters for network address translation and authorization rules.
该模型通过“云访问”容器提供云访问配置。云访问的使用是针对公共云的。互联网接入也可以被视为公共云接入服务。云访问容器为网络地址转换和授权规则提供参数。
A private cloud access may be addressed through NNIs, as described in Section 6.15.
如第6.15节所述，私有云访问可通过NNI解决。
A cloud identifier is used to reference the target service. This identifier is local to each administration.
云标识符用于引用目标服务。此标识符是每个管理的本地标识符。
The model allows for source address translation before accessing the cloud. IPv4-to-IPv4 address translation (NAT44) is the only supported option, but other options can be added through augmentation. If IP source address translation is required to access the cloud, the "enabled" leaf MUST be set to true in the "nat44" container. An IP address may be provided in the "customer-address" leaf if the customer is providing the IP address to be used for the cloud access. If the SP is providing this address, "customer-address" is not necessary, as it can be picked from a pool of SPs.
该模型允许在访问云之前进行源地址转换。IPv4到IPv4地址转换（NAT44）是唯一受支持的选项，但可以通过扩展添加其他选项。如果访问云需要IP源地址转换，则必须在“nat44”容器中将“enabled”叶设置为true。如果客户提供用于云访问的IP地址，则可以在“客户地址”页中提供IP地址。如果SP提供此地址，则不需要“客户地址”，因为它可以从SP池中选择。
By default, all sites in the IP VPN MUST be authorized to access the cloud. If restrictions are required, a user MAY configure the "permit-site" or "deny-site" leaf-list. The permit-site leaf-list defines the list of sites authorized for cloud access. The deny-site leaf-list defines the list of sites denied for cloud access. The model supports both "deny-any-except" and "permit-any-except" authorization.
默认情况下，IP VPN中的所有站点都必须获得访问云的授权。如果需要限制，用户可以配置“允许站点”或“拒绝站点”叶列表。许可站点叶列表定义了授权云访问的站点列表。拒绝站点叶列表定义拒绝云访问的站点列表。该模型支持“拒绝任何例外”和“允许任何例外”授权。
How the restrictions will be configured on network elements is out of scope for this document.
如何在网络元素上配置限制超出了本文档的范围。
IP VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
IP VPN
++++++++++++++++++++++++++++++++ ++++++++++++
+ Site 3 + --- + Cloud 1 +
+ Site 1 + ++++++++++++
+ +
+ Site 2 + --- ++++++++++++
+ + + Internet +
+ Site 4 + ++++++++++++
++++++++++++++++++++++++++++++++
|
+++++++++++
+ Cloud 2 +
+++++++++++
In the example above, we configure the global VPN to access the Internet by creating a cloud-access pointing to the cloud identifier for the Internet service. No authorized sites will be configured, as all sites are required to access the Internet. The "address-translation/nat44/enabled" leaf will be set to true.
在上面的示例中，我们通过创建指向Internet服务的云标识符的云访问来配置全局VPN以访问Internet。不会配置授权站点，因为所有站点都需要访问Internet。“地址转换/nat44/启用”叶将设置为true。
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
<address-translation>
<nat44>
<enabled>true</enabled>
</nat44>
</address-translation>
</cloud-access>
</cloud-accesses>
</vpn-service>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>INTERNET</cloud-identifier>
<address-translation>
<nat44>
<enabled>true</enabled>
</nat44>
</address-translation>
</cloud-access>
</cloud-accesses>
</vpn-service>
If Site 1 and Site 2 require access to Cloud 1, a new cloud-access pointing to the cloud identifier of Cloud 1 will be created. The permit-site leaf-list will be filled with a reference to Site 1 and Site 2.
如果站点1和站点2需要访问云1，将创建指向云1的云标识符的新云访问。许可证现场叶表将填写现场1和现场2的参考。
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud1</cloud-identifier>
<permit-site>site1</permit-site>
<permit-site>site2</permit-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud1</cloud-identifier>
<permit-site>site1</permit-site>
<permit-site>site2</permit-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
If all sites except Site 1 require access to Cloud 2, a new cloud-access pointing to the cloud identifier of Cloud 2 will be created. The deny-site leaf-list will be filled with a reference to Site 1.
如果站点1以外的所有站点都需要访问云2，则将创建指向云2的云标识符的新云访问。拒绝站点叶列表将填充对站点1的引用。
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud2</cloud-identifier>
<deny-site>site1</deny-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
<vpn-service>
<vpn-id>123456487</vpn-id>
<cloud-accesses>
<cloud-access>
<cloud-identifier>Cloud2</cloud-identifier>
<deny-site>site1</deny-site>
</cloud-access>
</cloud-accesses>
</vpn-service>
Multicast in IP VPNs is described in [RFC6513].
[RFC6513]中描述了IP VPN中的多播。
If multicast support is required for an IP VPN, some global multicast parameters are required as input for the service request.
如果IP VPN需要多播支持，则需要一些全局多播参数作为服务请求的输入。
Users of this model will need to provide the flavors of trees that will be used by customers within the IP VPN (customer tree). The proposed model supports bidirectional, shared, and source-based trees (and can be augmented). Multiple flavors of trees can be supported simultaneously.
此模型的用户需要提供IP VPN（客户树）中客户将使用的树的风格。该模型支持双向、共享和基于源的树（并且可以扩展）。可以同时支持多种风格的树。
Operator network
______________
/ \
| |
(SSM tree) |
Recv (IGMPv3) -- Site2 ------- PE2 |
| PE1 --- Site1 --- Source1
| | \
| | -- Source2
| |
(ASM tree) |
Recv (IGMPv2) -- Site3 ------- PE3 |
| |
(SSM tree) |
Recv (IGMPv3) -- Site4 ------- PE4 |
| / |
Recv (IGMPv2) -- Site5 -------- |
(ASM tree) |
| |
\_______________/
Operator network
______________
/ \
| |
(SSM tree) |
Recv (IGMPv3) -- Site2 ------- PE2 |
| PE1 --- Site1 --- Source1
| | \
| | -- Source2
| |
(ASM tree) |
Recv (IGMPv2) -- Site3 ------- PE3 |
| |
(SSM tree) |
Recv (IGMPv3) -- Site4 ------- PE4 |
| / |
Recv (IGMPv2) -- Site5 -------- |
(ASM tree) |
| |
\_______________/
When an ASM flavor is requested, this model requires that the "rp" and "rp-discovery" parameters be filled. Multiple RP-to-group mappings can be created using the "rp-group-mappings" container. For each mapping, the SP can manage the RP service by setting the "provider-managed/enabled" leaf to true. In the case of a provider-managed RP, the user can request RP redundancy and/or optimal traffic delivery. Those parameters will help the SP select the appropriate technology or architecture to fulfill the customer service requirement: for instance, in the case of a request for optimal traffic delivery, an SP may use Anycast-RP or RP-tree-to-SPT switchover architectures.
当请求ASM风格时，此模型要求填写“rp”和“rp发现”参数。可以使用“RP组映射”容器创建多个RP到组映射。对于每个映射，SP都可以通过将“提供者管理/启用”叶设置为true来管理RP服务。对于提供商管理的RP，用户可以请求RP冗余和/或最佳流量交付。这些参数将帮助SP选择适当的技术或体系结构以满足客户服务需求：例如，在请求最佳流量交付的情况下，SP可以使用Anycast RP或RP tree来实现SPT切换体系结构。
In the case of a customer-managed RP, the RP address must be filled in the RP-to-group mappings using the "rp-address" leaf. This leaf is not needed for a provider-managed RP.
对于客户管理的RP，必须使用“RP地址”页在RP到组的映射中填写RP地址。提供者管理的RP不需要此叶。
Users can define a specific mechanism for RP discovery, such as the "auto-rp", "static-rp", or "bsr-rp" modes. By default, the model uses "static-rp" if ASM is requested. A single rp-discovery mechanism is allowed for the VPN. The "rp-discovery" container can be used for both provider-managed and customer-managed RPs. In the case of a provider-managed RP, if the user wants to use "bsr-rp" as a discovery protocol, an SP should consider the provider-managed "rp-group-mappings" for the "bsr-rp" configuration. The SP will then configure its selected RPs to be "bsr-rp-candidates". In the case of a customer-managed RP and a "bsr-rp" discovery mechanism, the "rp-address" provided will be the bsr-rp candidate.
用户可以定义RP发现的特定机制，例如“自动RP”、“静态RP”或“bsr RP”模式。默认情况下，如果请求ASM，模型将使用“静态rp”。VPN允许使用单个rp发现机制。“rp发现”容器可用于提供商管理和客户管理的RPs。在提供者管理的RP的情况下，如果用户想要使用“BSR RP”作为发现协议，SP应该考虑“BSR RP”配置的提供者管理的“RP组映射”。然后，SP将其选定的rp配置为“bsr rp候选”。对于客户管理的RP和“bsr RP”发现机制，提供的“RP地址”将是bsr RP候选地址。
There are some cases where a particular VPN needs access to resources (servers, hosts, etc.) that are external. Those resources may be located in another VPN.
在某些情况下，特定VPN需要访问外部资源（服务器、主机等）。这些资源可能位于另一个VPN中。
+-----------+ +-----------+
/ \ / \
Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared
+-----------+ +-----------+ resources)
+-----------+ +-----------+
/ \ / \
Site A -- | VPN A | --- | VPN B | --- Site B
\ / \ / (Shared
+-----------+ +-----------+ resources)
In the figure above, VPN B has some resources on Site B that need to be available to some customers/partners. VPN A must be able to access those VPN B resources.
在上图中，VPN B在站点B上有一些资源需要提供给一些客户/合作伙伴。VPN A必须能够访问这些VPN B资源。
Such a VPN connection scenario can be achieved via a VPN policy as defined in Section 6.5.2.2. But there are some simple cases where a particular VPN (VPN A) needs access to all resources in another VPN (VPN B). The model provides an easy way to set up this connection using the "extranet-vpns" container.
这种VPN连接方案可以通过第6.5.2.2节中定义的VPN策略实现。但是，在一些简单的情况下，一个特定的VPN（VPN a）需要访问另一个VPN（VPN B）中的所有资源。该模型提供了一种使用“extranet VPN”容器设置此连接的简单方法。
The extranet-vpns container defines a list of VPNs a particular VPN wants to access. The extranet-vpns container must be used on customer VPNs accessing extranet resources in another VPN. In the figure above, in order to provide VPN A with access to VPN B, the extranet-vpns container needs to be configured under VPN A with an entry corresponding to VPN B. There is no service configuration requirement on VPN B.
extranet VPN容器定义特定VPN要访问的VPN列表。必须在访问另一个VPN中的extranet资源的客户VPN上使用extranet VPN容器。在上图中，为了向VPN A提供对VPN B的访问，需要在VPN A下配置extranet VPN容器，其中有一个与VPN B相对应的条目。VPN B上没有服务配置要求。
Readers should note that even if there is no configuration requirement on VPN B, if VPN A lists VPN B as an extranet, all sites in VPN B will gain access to all sites in VPN A.
读者应该注意，即使VPN B没有配置要求，如果VPN A将VPN B列为外联网，VPN B中的所有站点都将访问VPN A中的所有站点。
The "site-role" leaf defines the role of the local VPN sites in the target extranet VPN service topology. Site roles are defined in Section 6.4. Based on this, the requirements described in Section 6.4 regarding the site-role leaf are also applicable here.
“站点角色”叶定义目标外部网VPN服务拓扑中本地VPN站点的角色。第6.4节定义了现场角色。基于此，第6.4节中描述的关于现场角色叶的要求也适用于此处。
In the example below, VPN A accesses VPN B resources through an extranet connection. A Spoke role is required for VPN A sites, as sites from VPN A must not be able to communicate with each other through the extranet VPN connection.
在下面的示例中，VPN A通过外部网连接访问VPN B资源。VPN A站点需要分支角色，因为VPN A中的站点不能通过外部网VPN连接相互通信。
<vpn-service>
<vpn-id>VPNB</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<vpn-service-topology>any-to-any</vpn-service-topology>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</extranet-vpn>
</extranet-vpns>
</vpn-service>
<vpn-service>
<vpn-id>VPNB</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
<vpn-service>
<vpn-id>VPNA</vpn-id>
<vpn-service-topology>any-to-any</vpn-service-topology>
<extranet-vpns>
<extranet-vpn>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</extranet-vpn>
</extranet-vpns>
</vpn-service>
This model does not define how the extranet configuration will be achieved.
此模型没有定义如何实现外部网配置。
Any VPN interconnection scenario that is more complex (e.g., only certain parts of sites on VPN A accessing only certain parts of sites on VPN B) needs to be achieved using a VPN attachment as defined in Section 6.5.2, and especially a VPN policy as defined in Section 6.5.2.2.
需要使用第6.5.2节中定义的VPN附件，尤其是第6.5.2.2节中定义的VPN策略，实现任何更复杂的VPN互连场景（例如，仅VPN A上的某些站点部分访问VPN B上的某些站点部分）。
A site represents a connection of a customer office to one or more VPN services.
站点表示客户办公室与一个或多个VPN服务的连接。
+-------------+
/ \
+------------------+ +-----| VPN1 |
| | | \ /
| New York Office |------ (site) -----+ +-------------+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+
+-------------+
/ \
+------------------+ +-----| VPN1 |
| | | \ /
| New York Office |------ (site) -----+ +-------------+
| | | +-------------+
+------------------+ | / \
+-----| VPN2 |
\ /
+-------------+
A site has several characteristics:
场地有几个特点：
o Unique identifier (site-id): uniquely identifies the site within the overall network infrastructure. The identifier is a string that allows any encoding for the local administration of the VPN service.
o 唯一标识符（站点id）：在整个网络基础结构中唯一标识站点。标识符是一个字符串，允许对VPN服务的本地管理进行任何编码。
o Locations (locations): site location information that allows easy retrieval of information from the nearest available resources. A site may be composed of multiple locations.
o 位置（Locations）：允许从最近的可用资源轻松检索信息的站点位置信息。一个站点可以由多个位置组成。
o Devices (devices): allows the customer to request one or more customer premises equipment entities from the SP for a particular site.
o 设备（Devices）：允许客户为特定站点从SP请求一个或多个客户场所设备实体。
o Management (management): defines the type of management for the site -- for example, co-managed, customer-managed, or provider-managed. See Section 6.10.
o 管理（Management）：定义站点的管理类型——例如，共同管理、客户管理或提供商管理。见第6.10节。
o Site network accesses (site-network-accesses): defines the list of network accesses associated with the sites, and their properties -- especially bearer, connection, and service parameters.
o 站点网络访问（站点网络访问）：定义与站点关联的网络访问列表及其属性，特别是承载、连接和服务参数。
A site-network-access represents an IP logical connection of a site. A site may have multiple site-network-accesses.
站点网络访问表示站点的IP逻辑连接。一个站点可以有多个站点网络访问。
+------------------+ Site
| |-----------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-----------------------------------
+------------------+
+------------------+ Site
| |-----------------------------------
| |****** (site-network-access#1) ******
| New York Office |
| |****** (site-network-access#2) ******
| |-----------------------------------
+------------------+
Multiple site-network-accesses are used, for instance, in the case of multihoming. Some other meshing cases may also include multiple site-network-accesses.
例如，在多主的情况下，使用多站点网络访问。一些其他啮合情况也可能包括多个站点网络访问。
The site configuration is viewed as a global entity; we assume that it is mostly the management system's role to split the parameters between the different elements within the network. For example, in the case of the site-network-access configuration, the management system needs to split the overall parameters between the PE configuration and the CE configuration.
站点配置被视为一个全局实体；我们假设，在网络中的不同元素之间分割参数主要是管理系统的角色。例如，在站点网络访问配置的情况下，管理系统需要在PE配置和CE配置之间拆分总体参数。
A site may be composed of multiple locations. All the locations will need to be configured as part of the "locations" container and list. A typical example of a multi-location site is a headquarters office in a city composed of multiple buildings. Those buildings may be located in different parts of the city and may be linked by intra-city fibers (customer metropolitan area network). In such a case, when connecting to a VPN service, the customer may ask for multihoming based on its distributed locations.
一个站点可以由多个位置组成。所有位置都需要配置为“位置”容器和列表的一部分。多地点站点的一个典型示例是由多个建筑物组成的城市中的总部办公室。这些建筑物可能位于城市的不同部分，并可通过城内光纤（客户城域网）连接。在这种情况下，当连接到VPN服务时，客户可能会根据其分布的位置请求多归属。
New York Site
纽约站点
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |****** (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn | |****** (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+
A customer may also request some premises equipment entities (CEs) from the SP via the "devices" container. Requesting a CE implies a provider-managed or co-managed model. A particular device must be ordered to a particular already-configured location. This would help the SP send the device to the appropriate postal address. In a multi-location site, a customer may, for example, request a CE for each location on the site where multihoming must be implemented. In the figure above, one device may be requested for the Manhattan location and one other for the Brooklyn location.
客户还可以通过“设备”容器从SP请求某些场所设备实体（CE）。请求CE意味着提供程序管理或共同管理的模型。必须将特定设备订购到已配置的特定位置。这将有助于SP将设备发送到相应的邮政地址。例如，在多位置站点中，客户可以为站点上必须实施多主的每个位置请求CE。在上图中，一个设备可能被请求用于曼哈顿位置，另一个设备被请求用于布鲁克林位置。
By using devices and locations, the user can influence the multihoming scenario he wants to implement: single CE, dual CE, etc.
通过使用设备和位置，用户可以影响他想要实现的多主场景：单CE、双CE等。
As mentioned earlier, a site may be multihomed. Each IP network access for a site is defined in the "site-network-accesses" container. The site-network-access parameter defines how the site is connected on the network and is split into three main classes of parameters:
如前所述，站点可以是多址的。站点的每个IP网络访问都在“站点网络访问”容器中定义。站点网络访问参数定义站点在网络上的连接方式，并分为三类主要参数：
o bearer: defines requirements of the attachment (below Layer 3).
o 承载人：定义附件的要求（第3层以下）。
o connection: defines Layer 3 protocol parameters of the attachment.
o 连接：定义附件的第3层协议参数。
o availability: defines the site's availability policy. The availability parameters are defined in Section 6.7.
o 可用性：定义站点的可用性策略。第6.7节定义了可用性参数。
The site-network-access has a specific type (site-network-access-type). This document defines two types:
站点网络访问具有特定类型（站点网络访问类型）。本文件定义了两种类型：
o point-to-point: describes a point-to-point connection between the SP and the customer.
o 点对点：描述SP和客户之间的点对点连接。
o multipoint: describes a multipoint connection between the SP and the customer.
o 多点：描述SP和客户之间的多点连接。
The type of site-network-access may have an impact on the parameters offered to the customer, e.g., an SP may not offer encryption for multipoint accesses. It is up to the provider to decide what parameter is supported for point-to-point and/or multipoint accesses; this topic is out of scope for this document. Some containers proposed in the model may require extensions in order to work properly for multipoint accesses.
站点网络访问的类型可能会影响提供给客户的参数，例如，SP可能不会为多点访问提供加密。由提供商决定支持点到点和/或多点访问的参数；此主题超出了本文档的范围。模型中提出的一些容器可能需要扩展才能正确地用于多点访问。
The bearer container defines the requirements for the site attachment to the provider network that are below Layer 3.
承载容器定义了第3层以下的站点连接到提供商网络的要求。
The bearer parameters will help determine the access media to be used. This is further described in Section 6.6.3.
承载参数将有助于确定要使用的接入媒体。第6.6.3节对此作了进一步说明。
The "ip-connection" container defines the protocol parameters of the attachment (IPv4 and IPv6). Depending on the management mode, it refers to PE-CE addressing or CE-to-customer-LAN addressing. In any case, it describes the responsibility boundary between the provider and the customer. For a customer-managed site, it refers to the PE-CE connection. For a provider-managed site, it refers to the CE-to-LAN connection.
“ip连接”容器定义附件的协议参数（IPv4和IPv6）。根据管理模式，它指的是PE-CE寻址或CE到客户LAN寻址。无论如何，它描述了供应商和客户之间的责任边界。对于客户管理的站点，它指的是PE-CE连接。对于提供商管理的站点，它指的是CE到LAN的连接。
An IP subnet can be configured for either IPv4 or IPv6 Layer 3 protocols. For a dual-stack connection, two subnets will be provided, one for each address family.
可以为IPv4或IPv6第3层协议配置IP子网。对于双栈连接，将提供两个子网，每个地址族一个子网。
The "address-allocation-type" determines how the address allocation needs to be done. The current model proposes five ways to perform IP address allocation:
“地址分配类型”确定需要如何进行地址分配。当前模型提出了五种执行IP地址分配的方法：
o provider-dhcp: The provider will provide DHCP service for customer equipment; this is applicable to either the "IPv4" container or the "IPv6" container.
o 提供商dhcp：提供商将为客户设备提供dhcp服务；这适用于“IPv4”容器或“IPv6”容器。
o provider-dhcp-relay: The provider will provide DHCP relay service for customer equipment; this is applicable to both IPv4 and IPv6 addressing. The customer needs to populate the DHCP server list to be used.
o 提供商dhcp中继：提供商将为客户设备提供dhcp中继服务；这适用于IPv4和IPv6寻址。客户需要填写要使用的DHCP服务器列表。
o static-address: Addresses will be assigned manually; this is applicable to both IPv4 and IPv6 addressing.
o 静态地址：手动分配地址；这适用于IPv4和IPv6寻址。
o slaac: This parameter enables stateless address autoconfiguration [RFC4862]. This is applicable to IPv6 only.
o slaac：此参数启用无状态地址自动配置[RFC4862]。这仅适用于IPv6。
o provider-dhcp-slaac: The provider will provide DHCP service for customer equipment, as well as stateless address autoconfiguration. This is applicable to IPv6 only.
o 提供商dhcp slaac：提供商将为客户设备提供dhcp服务，以及无状态地址自动配置。这仅适用于IPv6。
In the dynamic addressing mechanism, the SP is expected to provide at least the IP address, mask, and default gateway information.
在动态寻址机制中，SP应至少提供IP地址、掩码和默认网关信息。
A customer may require a specific IP connectivity fault detection mechanism on the IP connection. The model supports BFD as a fault detection mechanism. This can be extended with other mechanisms via augmentation. The provider can propose some profiles to the
客户可能需要在IP连接上使用特定的IP连接故障检测机制。该模型支持BFD作为故障检测机制。这可以通过扩充与其他机制一起扩展。提供商可以向客户推荐一些配置文件
customer, depending on the service level the customer wants to achieve. Profile names must be communicated to the customer. This communication is out of scope for this document. Some fixed values for the holdtime period may also be imposed by the customer if the provider allows the customer this function.
客户，具体取决于客户希望达到的服务级别。配置文件名称必须传达给客户。此通信超出了本文档的范围。如果提供商允许客户使用此功能，则客户也可能会对保留时间段施加一些固定值。
The "oam" container can easily be augmented by other mechanisms; in particular, work done by the LIME Working Group (https://datatracker.ietf.org/wg/lime/charter/) may be reused in applicable scenarios.
“oam”容器可以很容易地通过其他机制进行扩充；特别是石灰工作组所做的工作(https://datatracker.ietf.org/wg/lime/charter/)可在适用场景中重复使用。
6.3.2.3. Inheritance of Parameters Defined at Site Level and Site Network Access Level
6.3.2.3. 在站点级别和站点网络访问级别定义的参数继承
Some parameters can be configured at both the site level and the site-network-access level, e.g., routing, services, security. Inheritance applies when parameters are defined at the site level. If a parameter is configured at both the site level and the access level, the access-level parameter MUST override the site-level parameter. Those parameters will be described later in this document.
可以在站点级别和站点网络访问级别配置一些参数，例如路由、服务、安全性。在站点级别定义参数时，继承适用。如果在站点级别和访问级别都配置了参数，则访问级别参数必须覆盖站点级别参数。这些参数将在本文件后面部分描述。
In terms of provisioning impact, it will be up to the implementation to decide on the appropriate behavior when modifying existing configurations. But the SP will need to communicate to the user about the impact of using inheritance. For example, if we consider that a site has already provisioned three site-network-accesses, what will happen if a customer changes a service parameter at the site level? An implementation of this model may update the service parameters of all already-provisioned site-network-accesses (with potential impact on live traffic), or it may take into account this new parameter only for the new sites.
就资源调配影响而言，在修改现有配置时，由实现决定适当的行为。但是SP需要与用户沟通使用继承的影响。例如，如果我们考虑一个站点已经提供了三个站点网络访问，如果客户在站点级别更改服务参数会发生什么？此模型的实现可能会更新所有已配置站点网络访问的服务参数（对实时流量有潜在影响），或者可能只考虑新站点的此新参数。
A VPN has a particular service topology, as described in Section 6.2.1. As a consequence, each site belonging to a VPN is assigned with a particular role in this topology. The site-role leaf defines the role of the site in a particular VPN topology.
VPN具有特定的服务拓扑，如第6.2.1节所述。因此，属于VPN的每个站点在此拓扑中都分配了特定的角色。站点角色叶定义站点在特定VPN拓扑中的角色。
In the any-to-any VPN service topology, all sites MUST have the same role, which will be "any-to-any-role".
在任意对任意VPN服务拓扑中，所有站点必须具有相同的角色，即“任意对任意角色”。
In the Hub-and-Spoke VPN service topology or the Hub and Spoke disjoint VPN service topology, sites MUST have a Hub role or a Spoke role.
在集线器和分支VPN服务拓扑或集线器和分支不相交VPN服务拓扑中，站点必须具有集线器角色或分支角色。
A site may be part of one or multiple VPNs. The "site-vpn-flavor" defines the way the VPN multiplexing is done. The current version of the model supports four flavors:
一个站点可以是一个或多个VPN的一部分。“站点vpn风格”定义了vpn多路复用的方式。当前版本的模型支持四种风格：
o site-vpn-flavor-single: The site belongs to only one VPN.
o 站点vpn：该站点只属于一个vpn。
o site-vpn-flavor-multi: The site belongs to multiple VPNs, and all the logical accesses of the sites belong to the same set of VPNs.
o site vpn flavor multi：站点属于多个vpn，所有站点的逻辑访问都属于同一组vpn。
o site-vpn-flavor-sub: The site belongs to multiple VPNs with multiple logical accesses. Each logical access may map to different VPNs (one or many).
o site vpn flavor sub：该站点属于具有多个逻辑访问的多个vpn。每个逻辑访问可以映射到不同的VPN（一个或多个）。
o site-vpn-flavor-nni: The site represents an option A NNI.
o 站点vpn风格nni：该站点表示nni选项。
The figure below describes a single VPN attachment. The site connects to only one VPN.
下图描述了单个VPN附件。该站点仅连接到一个VPN。
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+
+--------+
+------------------+ Site / \
| |-----------------------------| |
| |***(site-network-access#1)***| VPN1 |
| New York Office | | |
| |***(site-network-access#2)***| |
| |-----------------------------| |
+------------------+ \ /
+--------+
The figure below describes a site connected to multiple VPNs.
下图描述了连接到多个VPN的站点。
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+
+---------+
+---/----+ \
+------------------+ Site / | \ |
| |--------------------------------- | |VPN B|
| |***(site-network-access#1)******* | | |
| New York Office | | | | |
| |***(site-network-access#2)******* \ | /
| |-----------------------------| VPN A+-----|---+
+------------------+ \ /
+--------+
In the example above, the New York office is multihomed. Both logical accesses are using the same VPN attachment rules, and both are connected to VPN A and VPN B.
在上面的例子中，纽约办事处是多址的。两个逻辑访问都使用相同的VPN连接规则，并且都连接到VPN A和VPN B。
Reaching VPN A or VPN B from the New York office will be done via destination-based routing. Having the same destination reachable from the two VPNs may cause routing troubles. The customer administration's role in this case would be to ensure the appropriate mapping of its prefixes in each VPN.
从纽约办事处到达VPN A或VPN B将通过基于目的地的路由完成。如果两个VPN可以到达相同的目的地，则可能会导致路由问题。在这种情况下，客户管理的作用是确保在每个VPN中正确映射其前缀。
The figure below describes a subVPN attachment. The site connects to multiple VPNs, but each logical access is attached to a particular set of VPNs. A typical use case for a subVPN is a customer site used by multiple affiliates with private resources for each affiliate that cannot be shared (communication between the affiliates is prevented). It is similar to having separate sites, but in this case the customer wants to share some physical components while maintaining strong communication isolation between the affiliates. In this example, site-network-access#1 is attached to VPN B, while site-network-access#2 is attached to VPN A.
下图描述了subVPN附件。站点连接到多个VPN，但每个逻辑访问都连接到一组特定的VPN。subVPN的典型用例是多个分支机构使用的客户站点，每个分支机构的私有资源无法共享（分支机构之间的通信被阻止）。这类似于拥有单独的站点，但在这种情况下，客户希望共享一些物理组件，同时在附属公司之间保持强大的通信隔离。在本例中，站点网络访问#1连接到VPN B，而站点网络访问#2连接到VPN A。
+------------------+ Site +--------+
| |----------------------------------/ \
| |****(site-network-access#1)******| VPN B |
| New York Office | \ /
| | +--------+
| | +--------+
| | / \
| |****(site-network-access#2)******| VPN A |
| | \ /
| | +--------+
| |-----------------------------------
+------------------+
+------------------+ Site +--------+
| |----------------------------------/ \
| |****(site-network-access#1)******| VPN B |
| New York Office | \ /
| | +--------+
| | +--------+
| | / \
| |****(site-network-access#2)******| VPN A |
| | \ /
| | +--------+
| |-----------------------------------
+------------------+
A multiVPN can be implemented in addition to a subVPN; as a consequence, each site-network-access can access multiple VPNs. In the example below, site-network-access#1 is mapped to VPN B and VPN C, while site-network-access#2 is mapped to VPN A and VPN D.
除了子VPN之外，还可以实现多VPN；因此，每个站点网络访问都可以访问多个VPN。在下面的示例中，站点网络访问#1映射到VPN B和VPN C，而站点网络访问#2映射到VPN A和VPN D。
+-----------------+ Site +------+
| |--------------------------------/ +-----+
| |****(site-network-access#1)****| VPN B / \
| New York Office | \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +-------+
| | / +-----+
| |****(site-network-access#2)****| VPN A / \
| | \ | VPN D |
| | +------\ /
| |--------------------------------- +-----+
+-----------------+
+-----------------+ Site +------+
| |--------------------------------/ +-----+
| |****(site-network-access#1)****| VPN B / \
| New York Office | \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +-------+
| | / +-----+
| |****(site-network-access#2)****| VPN A / \
| | \ | VPN D |
| | +------\ /
| |--------------------------------- +-----+
+-----------------+
Multihoming is also possible with subVPNs; in this case, site-network-accesses are grouped, and a particular group will have access to the same set of VPNs. In the example below, site-network-access#1 and site-network-access#2 are part of the same group (multihomed together) and are mapped to VPN B and VPN C; in addition, site-network-access#3 and site-network-access#4 are part of the same group (multihomed together) and are mapped to VPN A and VPN D.
子VPN也可以实现多主定位；在这种情况下，站点网络访问是分组的，特定的组将访问同一组VPN。在下面的示例中，站点网络访问#1和站点网络访问#2属于同一组（多址在一起），并映射到VPN B和VPN C；此外，站点网络访问#3和站点网络访问#4属于同一组（多址在一起），并映射到VPN A和VPN D。
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)***** \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN A / \
| |****(site-network-access#4)***** \ | VPN D |
| | +-----\ /
| |---------------------------------- +-----+
+-----------------+
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)***** \ | VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN A / \
| |****(site-network-access#4)***** \ | VPN D |
| | +-----\ /
| |---------------------------------- +-----+
+-----------------+
In terms of service configuration, a subVPN can be achieved by requesting that the site-network-access use the same bearer (see Sections 6.6.4 and 6.6.6.4 for more details).
就服务配置而言，可以通过请求站点网络访问使用相同的承载来实现子VPN（有关更多详细信息，请参见第6.6.4节和第6.6.6.4节）。
A Network-to-Network Interface (NNI) scenario may be modeled using the sites container (see Section 6.15.1). Using the sites container to model an NNI is only one possible option for NNIs (see Section 6.15). This option is called "option A" by reference to the option A NNI defined in [RFC4364]. It is helpful for the SP to indicate that the requested VPN connection is not a regular site but rather is an NNI, as specific default device configuration parameters may be applied in the case of NNIs (e.g., ACLs, routing policies).
网络到网络接口（NNI）场景可使用站点容器建模（见第6.15.1节）。使用站点容器对NNI建模只是NNI的一个可能选项（见第6.15节）。参考[RFC4364]中定义的选项A NNI，该选项称为“选项A”。SP指出请求的VPN连接不是常规站点，而是NNI是很有帮助的，因为特定的默认设备配置参数可能会应用于NNI（例如ACL、路由策略）。
SP A SP B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
SP A SP B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
The figure above describes an option A NNI scenario that can be modeled using the sites container. In order to connect its customer VPNs (VPN1 and VPN2) in SP B, SP A may request the creation of some site-network-accesses to SP B. The site-vpn-flavor-nni will be used to inform SP B that this is an NNI and not a regular customer site. The site-vpn-flavor-nni may be multihomed and multiVPN as well.
上图描述了一个选项A NNI场景，该场景可以使用sites容器进行建模。为了连接SP B中的客户vpn（VPN1和VPN2），SP A可能会请求创建一些到SP B的站点网络访问。站点vpn风格nni将用于通知SP B这是nni，而不是常规客户站点。站点vpn也可以是多址和多vpn。
Due to the multiple site-vpn flavors, the attachment of a site to an IP VPN is done at the site-network-access (logical access) level through the "vpn-attachment" container. The vpn-attachment container is mandatory. The model provides two ways to attach a site to a VPN:
由于多站点vpn的特性，站点到IP vpn的连接是通过“vpn连接”容器在站点网络访问（逻辑访问）级别完成的。vpn附件容器是必需的。该模型提供了两种将站点连接到VPN的方法：
o By referencing the target VPN directly.
o 通过直接引用目标VPN。
o By referencing a VPN policy for attachments that are more complex.
o 通过为更复杂的附件引用VPN策略。
A choice is implemented to allow the user to choose the flavor that provides the best fit.
实现了一种选择，允许用户选择最适合的口味。
Referencing a vpn-id provides an easy way to attach a particular logical access to a VPN. This is the best way in the case of a single VPN attachment or subVPN with a single VPN attachment per logical access. When referencing a vpn-id, the site-role setting must be added to express the role of the site in the target VPN service topology.
引用vpn id提供了将特定逻辑访问连接到vpn的简单方法。对于单个VPN附件或每个逻辑访问具有单个VPN附件的子VPN，这是最好的方法。引用vpn id时，必须添加站点角色设置，以表示站点在目标vpn服务拓扑中的角色。
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>LA2</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>LA2</site-network-access-id>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
The example above describes a subVPN case where a site (SITE1) has two logical accesses (LA1 and LA2), with LA1 attached to VPNA and LA2 attached to VPNB.
上面的示例描述了一个子VPN情况，其中站点（SITE1）有两个逻辑访问（LA1和LA2），LA1连接到VPNA，LA2连接到VPNB。
The "vpn-policy" list helps express a multiVPN scenario where a logical access belongs to multiple VPNs. Multiple VPN policies can be created to handle the subVPN case where each logical access is part of a different set of VPNs.
“vpn策略”列表有助于表示逻辑访问属于多个vpn的多vpn场景。可以创建多个VPN策略来处理子VPN情况，其中每个逻辑访问都是不同VPN集的一部分。
As a site can belong to multiple VPNs, the vpn-policy list may be composed of multiple entries. A filter can be applied to specify that only some LANs of the site should be part of a particular VPN. Each time a site (or LAN) is attached to a VPN, the user must precisely describe its role (site-role) within the target VPN service topology.
由于一个站点可以属于多个vpn，vpn策略列表可能由多个条目组成。可以应用筛选器来指定只有站点的某些LAN应该是特定VPN的一部分。每次站点（或LAN）连接到VPN时，用户必须准确描述其在目标VPN服务拓扑中的角色（站点角色）。
+--------------------------------------------------------------+
| Site1 ------ PE7 |
+-------------------------+ [VPN2] |
| |
+-------------------------+ |
| Site2 ------ PE3 PE4 ------ Site3 |
+----------------------------------+ |
| |
+------------------------------------------------------------+ |
| Site4 ------ PE5 | PE6 ------ Site5 | |
| | |
| [VPN3] | |
+------------------------------------------------------------+ |
| |
+---------------------------+
+--------------------------------------------------------------+
| Site1 ------ PE7 |
+-------------------------+ [VPN2] |
| |
+-------------------------+ |
| Site2 ------ PE3 PE4 ------ Site3 |
+----------------------------------+ |
| |
+------------------------------------------------------------+ |
| Site4 ------ PE5 | PE6 ------ Site5 | |
| | |
| [VPN3] | |
+------------------------------------------------------------+ |
| |
+---------------------------+
In the example above, Site5 is part of two VPNs: VPN3 and VPN2. It will play a Hub role in VPN2 and an any-to-any role in VPN3. We can express such a multiVPN scenario as follows:
在上面的示例中，Site5是两个VPN的一部分：VPN3和VPN2。它将在VPN2中扮演中心角色，在VPN3中扮演任意对任意角色。我们可以将这种多VPN场景表示为：
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<entries>
<id>ENTRY2</id>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
Now, if a more-granular VPN attachment is necessary, filtering can be used. For example, if LAN1 from Site5 must be attached to VPN2 as a Hub and LAN2 must be attached to VPN3, the following configuration can be used:
现在，如果需要更细粒度的VPN附件，可以使用过滤。例如，如果站点5中的LAN1必须作为集线器连接到VPN2，并且LAN2必须连接到VPN3，则可以使用以下配置：
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<filter>
<lan-tag>LAN1</lan-tag>
</filter>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<filter>
<lan-tag>LAN2</lan-tag>
</filter>
<site>
<site-id>Site5</site-id>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>POLICY1</vpn-policy-id>
<entries>
<id>ENTRY1</id>
<filter>
<lan-tag>LAN1</lan-tag>
</filter>
<vpn>
<vpn-id>VPN2</vpn-id>
<site-role>hub-role</site-role>
</vpn>
</entries>
<entries>
<id>ENTRY2</id>
<filter>
<lan-tag>LAN2</lan-tag>
</filter>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<vpn>
<vpn-id>VPN3</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
<site-network-accesses>
<site-network-access>
<site-network-access-id>LA1</site-network-access-id>
<vpn-attachment>
<vpn-policy-id>POLICY1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
The management system will have to determine where to connect each site-network-access of a particular site to the provider network (e.g., PE, aggregation switch).
管理系统必须确定将特定站点的每个站点网络访问连接到提供商网络（例如PE、聚合交换机）的位置。
The current model proposes parameters and constraints that can influence the meshing of the site-network-access.
当前模型提出了可能影响站点网络访问网格划分的参数和约束。
The management system SHOULD honor any customer constraints. If a constraint is too strict and cannot be fulfilled, the management system MUST NOT provision the site and SHOULD provide relevant information to the user. How the information is provided is out of scope for this document. Whether or not to relax the constraint would then be left up to the user.
管理体系应尊重任何客户约束。如果约束过于严格且无法满足，则管理系统不得提供现场，并应向用户提供相关信息。如何提供信息超出了本文件的范围。然后，是否放松约束将由用户决定。
Parameters are just hints for the management system for service placement.
参数只是服务放置管理系统的提示。
In addition to parameters and constraints, the management system's decision MAY be based on any other internal constraints that are left up to the SP: least load, distance, etc.
除参数和约束外，管理系统的决策可能基于SP的任何其他内部约束：最小负载、距离等。
In the case of provider management or co-management, one or more devices have been ordered by the customer. The customer may force a particular site-network-access to be connected on a particular device that he ordered.
在供应商管理或共同管理的情况下，客户已订购一台或多台设备。客户可以强制将特定站点网络访问连接到其订购的特定设备上。
New York Site
纽约站点
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |
| | CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn CE2********* (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+
+------------------+ Site
| +--------------+ |-----------------------------------
| | Manhattan | |
| | CE1********* (site-network-access#1) ******
| +--------------+ |
| +--------------+ |
| | Brooklyn CE2********* (site-network-access#2) ******
| +--------------+ |
| |-----------------------------------
+------------------+
In the figure above, site-network-access#1 is associated with CE1 in the service request. The SP must ensure the provisioning of this connection.
在上图中，站点网络访问#1与服务请求中的CE1相关联。SP必须确保配置此连接。
The location information provided in this model MAY be used by a management system to determine the target PE to mesh the site (SP side). A particular location must be associated with each site network access when configuring it. The SP MUST honor the termination of the access on the location associated with the site network access (customer side). The "country-code" in the site location SHOULD be expressed as an ISO ALPHA-2 code.
管理系统可以使用此模型中提供的位置信息来确定要与站点（SP侧）啮合的目标PE。配置时，特定位置必须与每个站点网络访问相关联。SP必须在与站点网络访问相关的位置（客户端）终止访问。现场位置中的“国家代码”应表示为ISO ALPHA-2代码。
The site-network-access location is determined by the "location-flavor". In the case of a provider-managed or co-managed site, the user is expected to configure a "device-reference" (device case) that will bind the site-network-access to a particular device that the customer ordered. As each device is already associated with a particular location, in such a case the location information is retrieved from the device location. In the case of a customer-managed site, the user is expected to configure a "location-reference" (location case); this provides a reference to an existing configured location and will help with placement.
站点网络访问位置由“位置风格”决定。对于供应商管理或共同管理的站点，用户需要配置“设备参考”（设备案例），将站点网络访问绑定到客户订购的特定设备。由于每个设备已经与特定位置相关联，在这种情况下，从设备位置检索位置信息。对于客户管理的站点，用户需要配置“位置参考”（位置案例）；这将提供对现有配置位置的引用，并有助于放置。
POP#1 (New York)
+---------+
| PE1 |
Site #1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
POP#1 (New York)
+---------+
| PE1 |
Site #1 ---... | PE2 |
(Atlantic City) | PE3 |
+---------+
POP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
POP#2 (Washington)
+---------+
| PE4 |
| PE5 |
| PE6 |
+---------+
POP#3 (Philadelphia)
+---------+
| PE7 |
Site #2 CE#1---... | PE8 |
(Reston) | PE9 |
+---------+
POP#3 (Philadelphia)
+---------+
| PE7 |
Site #2 CE#1---... | PE8 |
(Reston) | PE9 |
+---------+
In the example above, Site #1 is a customer-managed site with a location L1, while Site #2 is a provider-managed site for which a CE (CE#1) was ordered. Site #2 is configured with L2 as its location. When configuring a site-network-access for Site #1, the user will need to reference location L1 so that the management system will know that the access will need to terminate on this location. Then, for distance reasons, this management system may mesh Site #1 on a PE in the Philadelphia POP. It may also take into account resources available on PEs to determine the exact target PE (e.g., least loaded). For Site #2, the user is expected to configure the site-network-access with a device-reference to CE#1 so that the management system will know that the access must terminate on the location of CE#1 and must be connected to CE#1. For placement of the SP side of the access connection, in the case of the nearest PE used, it may mesh Site #2 on the Washington POP.
在上面的示例中，站点#1是位置为L1的客户管理站点，而站点#2是订购CE（CE#1）的供应商管理站点。站点#2配置为L2作为其位置。为站点#1配置站点网络访问时，用户需要参考位置L1，以便管理系统知道访问需要在该位置终止。然后，由于距离的原因，该管理系统可能会与费城流行音乐厅PE上的站点#1相匹配。它还可以考虑PEs上可用的资源，以确定确切的目标PE（例如，负载最少）。对于站点#2，用户需要使用对CE#1的设备引用来配置站点网络访问，以便管理系统知道访问必须在CE#1的位置终止，并且必须连接到CE#1。对于接入连接的SP侧的放置，如果使用的是最近的PE，则其可能与华盛顿POP上的站点2啮合。
The management system needs to elect the access media to connect the site to the customer (for example, xDSL, leased line, Ethernet backhaul). The customer may provide some parameters/constraints that will provide hints to the management system.
管理系统需要选择接入介质将站点连接到客户（例如，xDSL、专线、以太网回程）。客户可能会提供一些参数/约束，为管理系统提供提示。
The bearer container information SHOULD be the first piece of information considered when making this decision:
不记名集装箱信息应是做出此决定时考虑的第一条信息：
o The "requested-type" parameter provides information about the media type that the customer would like to use. If the "strict" leaf is equal to "true", this MUST be considered a strict constraint so that the management system cannot connect the site with another media type. If the "strict" leaf is equal to "false" (default) and if the requested media type cannot be fulfilled, the management system can select another media type. The supported media types SHOULD be communicated by the SP to the customer via a mechanism that is out of scope for this document.
o “requested type”参数提供有关客户希望使用的介质类型的信息。如果“strict”页等于“true”，则必须将其视为严格约束，以便管理系统无法将站点连接到其他媒体类型。如果“strict”页等于“false”（默认值），并且如果无法满足请求的媒体类型，则管理系统可以选择其他媒体类型。支持的媒体类型应由SP通过本文档范围之外的机制传达给客户。
o The "always-on" leaf defines a strict constraint: if set to true, the management system MUST elect a media type that is "always-on" (e.g., this means no dial access type).
o “始终打开”叶定义了一个严格的约束：如果设置为true，管理系统必须选择“始终打开”的媒体类型（例如，这意味着没有拨号访问类型）。
o The "bearer-reference" parameter is used in cases where the customer has already ordered a network connection to the SP apart from the IP VPN site and wants to reuse this connection. The string used is an internal reference from the SP and describes the already-available connection. This is also a strict requirement that cannot be relaxed. How the reference is given to the customer is out of scope for this document, but as a pure example, when the customer ordered the bearer (through a process that is out of scope for this model), the SP may have provided the bearer reference that can be used for provisioning services on top.
o “承载参考”参数用于以下情况：客户已经订购了与SP的网络连接（IP VPN站点除外），并希望重新使用此连接。使用的字符串是SP的内部引用，用于描述已可用的连接。这也是一项不能放松的严格要求。如何向客户提供参考超出了本文档的范围，但作为一个纯粹的示例，当客户订购承载物（通过本模型范围之外的流程）时，SP可能已经提供了可用于在顶部提供服务的承载物参考。
Any other internal parameters from the SP can also be used. The management system MAY use other parameters, such as the requested "svc-input-bandwidth" and "svc-output-bandwidth", to help decide which access type to use.
也可以使用SP的任何其他内部参数。管理系统可以使用其他参数，例如请求的“svc输入带宽”和“svc输出带宽”，来帮助决定使用哪种接入类型。
Each site-network-access may have one or more constraints that would drive the placement of the access. By default, the model assumes that there are no constraints, but allocation of a unique bearer per site-network-access is expected.
每个站点网络访问可能有一个或多个约束，这些约束将驱动访问的放置。默认情况下，该模型假设不存在约束，但预期每个站点网络访问分配唯一的承载。
In order to help with the different placement scenarios, a site-network-access may be tagged using one or multiple group identifiers. The group identifier is a string, so it can accommodate both explicit naming of a group of sites (e.g., "multihomed-set1" or "subVPN") and the use of a numbered identifier (e.g., 12345678). The meaning of each group-id is local to each customer administrator, and the management system MUST ensure that different customers can use the same group-ids. One or more group-ids can also be defined at the
为了帮助不同的放置场景，可以使用一个或多个组标识符标记站点网络访问。组标识符是一个字符串，因此它可以同时容纳一组站点的显式命名（例如，“多址set1”或“subVPN”）和使用编号标识符（例如12345678）。每个组id的含义对于每个客户管理员都是本地的，管理系统必须确保不同的客户可以使用相同的组id。一个或多个组ID也可以在
site level; as a consequence, all site-network-accesses under the site MUST inherit the group-ids of the site they belong to. When, in addition to the site group-ids some group-ids are defined at the site-network-access level, the management system MUST consider the union of all groups (site level and site network access level) for this particular site-network-access.
站点级别；因此，站点下的所有站点网络访问必须继承其所属站点的组ID。当除了站点组ID之外，在站点网络访问级别定义了一些组ID时，管理系统必须考虑所有的组（站点级别和站点网络访问级别）的联合以用于该特定站点网络访问。
For an already-configured site-network-access, each constraint MUST be expressed against a targeted set of site-network-accesses. This site-network-access MUST never be taken into account in the targeted set -- for example, "My site-network-access S must not be connected on the same POP as the site-network-accesses that are part of Group 10." The set of site-network-accesses against which the constraint is evaluated can be expressed as a list of groups, "all-other-accesses", or "all-other-groups". The all-other-accesses option means that the current site-network-access constraint MUST be evaluated against all the other site-network-accesses belonging to the current site. The all-other-groups option means that the constraint MUST be evaluated against all groups that the current site-network-access does not belong to.
对于已配置的站点网络访问，必须针对一组目标站点网络访问表达每个约束。在目标集合中决不能考虑此站点网络访问--例如，“我的站点网络访问不能与属于组10的站点网络访问连接在同一个POP上。”评估约束的站点网络访问集合可以表示为组列表，“所有其他访问”，或“所有其他群体”。“所有其他访问”选项意味着必须根据属于当前站点的所有其他站点网络访问来评估当前站点网络访问约束。“所有其他组”选项意味着必须针对当前站点网络访问不属于的所有组评估约束。
The current model proposes multiple constraint-types:
当前模型提出了多种约束类型：
o pe-diverse: The current site-network-access MUST NOT be connected to the same PE as the targeted site-network-accesses.
o pe多样化：当前站点网络访问不得连接到与目标站点网络访问相同的pe。
o pop-diverse: The current site-network-access MUST NOT be connected to the same POP as the targeted site-network-accesses.
o pop多样化：当前站点网络访问不得连接到与目标站点网络访问相同的pop。
o linecard-diverse: The current site-network-access MUST NOT be connected to the same linecard as the targeted site-network-accesses.
o 线路卡多样性：当前站点网络访问不得连接到与目标站点网络访问相同的线路卡。
o bearer-diverse: The current site-network-access MUST NOT use common bearer components compared to bearers used by the targeted site-network-accesses. "bearer-diverse" provides some level of diversity at the access level. As an example, two bearer-diverse site-network-accesses must not use the same DSLAM, BAS, or Layer 2 switch.
o 承载多样化：与目标站点网络访问使用的承载相比，当前站点网络访问不得使用公共承载组件。“承载多样性”在接入层提供一定程度的多样性。例如，两个承载不同站点网络访问不得使用相同的DSLAM、BAS或第2层交换机。
o same-pe: The current site-network-access MUST be connected to the same PE as the targeted site-network-accesses.
o 相同pe：当前站点网络访问必须连接到与目标站点网络访问相同的pe。
o same-bearer: The current site-network-access MUST be connected using the same bearer as the targeted site-network-accesses.
o 相同承载：当前站点网络访问必须使用与目标站点网络访问相同的承载进行连接。
These constraint-types can be extended through augmentation.
这些约束类型可以通过扩充进行扩展。
Each constraint is expressed as "The site-network-access S must be <constraint-type> (e.g., pe-diverse, pop-diverse) from these <target> site-network-accesses."
每个约束都表示为“站点网络访问必须是这些<target>站点网络访问的<constraint type>（例如，pe多样化、pop多样化）。”
The group-id used to target some site-network-accesses may be the same as the one used by the current site-network-access. This eases the configuration of scenarios where a group of site-network-access points has a constraint between the access points in the group. As an example, if we want a set of sites (Site#1 to Site#5) to be connected on different PEs, we can tag them with the same group-id and express a pe-diverse constraint for this group-id.
用于针对某些站点网络访问的组id可能与当前站点网络访问使用的组id相同。这简化了一组站点网络接入点在组中的接入点之间具有约束的场景的配置。例如，如果我们希望一组站点（站点1到站点5）连接到不同的pe上，我们可以使用相同的组id标记它们，并为此组id表示pe多样性约束。
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
<site>
<site-id>SITE2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
The group-id used to target some site-network-accesses may also be different than the one used by the current site-network-access. This can be used to express that a group of sites has some constraints against another group of sites, but there is no constraint within the group. For example, we consider a set of six sites and two groups; we want to ensure that a site in the first group must be pop-diverse from a site in the second group:
用于针对某些站点网络访问的组id也可能不同于当前站点网络访问使用的组id。这可以用来表示一组站点对另一组站点有一些约束，但组内没有约束。例如，我们考虑一组六个站点和两个组；我们希望确保第一组中的站点必须与第二组中的站点不同：
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</site>
<site>
<site-id>SITE2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
...
<site>
<site-id>SITE5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE6</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE6</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
Some infeasible access placement scenarios could be created via the proposed configuration framework. Such infeasible access placement scenarios could result from constraints that are too restrictive, leading to infeasible access placement in the network or conflicting
通过建议的配置框架可以创建一些不可行的访问放置场景。这种不可行的访问放置场景可能是由于限制太严格，导致网络中不可行的访问放置或冲突
constraints that would also lead to infeasible access placement. An example of conflicting rules would be to request that site-network-access#1 be pe-diverse from site-network-access#2 and to request at the same time that site-network-access#2 be on the same PE as site-network-access#1. When the management system cannot determine the placement of a site-network-access, it SHOULD return an error message indicating that placement was not possible.
也会导致不可行的访问位置的约束。冲突规则的一个例子是请求站点网络访问#1与站点网络访问#2不同，同时请求站点网络访问#2与站点网络访问#1位于同一pe上。当管理系统无法确定站点网络访问的位置时，应返回一条错误消息，指示无法放置。
The customer wants to create a multihomed site. The site will be composed of two site-network-accesses; for resiliency purposes, the customer wants the two site-network-accesses to be meshed on different POPs.
客户希望创建一个多址站点。该站点将由两个站点网络访问组成；出于弹性目的，客户希望两个站点网络访问在不同的POP上啮合。
POP#1
+-------+ +---------+
| | | PE1 |
| |---site-network-access#1----| PE2 |
| | | PE3 |
| | +---------+
| Site#1|
| | POP#2
| | +---------+
| | | PE4 |
| |---site-network-access#2----| PE5 |
| | | PE6 |
| | +---------+
+-------+
POP#1
+-------+ +---------+
| | | PE1 |
| |---site-network-access#1----| PE2 |
| | | PE3 |
| | +---------+
| Site#1|
| | POP#2
| | +---------+
| | | PE4 |
| |---site-network-access#2----| PE5 |
| | | PE6 |
| | +---------+
+-------+
This scenario can be expressed as follows:
这种情况可以表示为：
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
But it can also be expressed as follows:
但它也可以表示为：
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<all-other-accesses/>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
The customer has six branch offices in a particular region, and he wants to prevent having all branch offices connected on the same PE.
客户在特定地区有六个分支机构，他希望防止所有分支机构在同一个PE上连接。
He wants to express that three branch offices cannot be connected on the same linecard. Also, the other branch offices must be connected on a different POP. Those other branch offices cannot also be connected on the same linecard.
他想表示，三个分支机构不能在同一个线路卡上连接。此外，其他分支机构必须通过不同的POP连接。这些其他分支机构也不能在同一线路卡上连接。
POP#1
+---------+
| PE1 |
Office#1 ---... | PE2 |
Office#2 ---... | PE3 |
Office#3 ---... | PE4 |
+---------+
POP#1
+---------+
| PE1 |
Office#1 ---... | PE2 |
Office#2 ---... | PE3 |
Office#3 ---... | PE4 |
+---------+
POP#2
+---------+
Office#4 ---... | PE5 |
Office#5 ---... | PE6 |
Office#6 ---... | PE7 |
+---------+
POP#2
+---------+
Office#4 ---... | PE5 |
Office#5 ---... | PE6 |
Office#6 ---... | PE7 |
+---------+
This scenario can be expressed as follows:
这种情况可以表示为：
o We need to create two groups of sites: Group#10, which is composed of Office#1, Office#2, and Office#3; and Group#20, which is composed of Office#4, Office#5, and Office#6.
o 我们需要创建两组站点：Group#10，由Office#1、Office#2和Office#3组成；第20组，由4号办公室、5号办公室和6号办公室组成。
o Sites within Group#10 must be pop-diverse from sites within Group#20, and vice versa.
o 组10内的站点必须与组20内的站点不同，反之亦然。
o Sites within Group#10 must be linecard-diverse from other sites in Group#10 (same for Group#20).
o 第10组内的站点必须与第10组内的其他站点不同（第20组相同）。
<site>
<site-id>Office1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<site>
<site-id>Office1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office2</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office3</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office3</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>10</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office4</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office4</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office5</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office6</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>Office6</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pop-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>linecard-diverse</constraint-type>
<target>
<group>
<group-id>20</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNA</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
To increase its site bandwidth at lower cost, a customer wants to order two parallel site-network-accesses that will be connected to the same PE.
为了以较低的成本增加其站点带宽，客户希望订购两个将连接到同一PE的并行站点网络访问。
*******site-network-access#1**********
Site 1 *******site-network-access#2********** PE1
*******site-network-access#1**********
Site 1 *******site-network-access#2********** PE1
This scenario can be expressed as follows:
这种情况可以表示为：
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<constraints>
<constraint>
<constraint-type>same-pe</constraint-type>
<target>
<group>
<group-id>PE-linkgrp-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
A customer has a site that is dual-homed. The dual-homing must be done on two different PEs. The customer also wants to implement two subVPNs on those multihomed accesses.
客户有一个双主机站点。必须在两个不同的PEs上进行双重归位。客户还希望在这些多址访问上实现两个子VPN。
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)************| VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN B / \
| |****(site-network-access#4)************| VPN C |
| | +-----\ /
| |----------------------------------- +-----+
+-----------------+
+-----------------+ Site +------+
| |---------------------------------/ +-----+
| |****(site-network-access#1)*****| VPN B / \
| New York Office |****(site-network-access#2)************| VPN C |
| | +-----\ /
| | +-----+
| |
| | +------+
| | / +-----+
| |****(site-network-access#3)*****| VPN B / \
| |****(site-network-access#4)************| VPN C |
| | +-----\ /
| |----------------------------------- +-----+
+-----------------+
This scenario can be expressed as follows:
这种情况可以表示为：
o The site will have four site network accesses (two subVPNs coupled via dual-homing).
o 该站点将有四个站点网络访问（两个通过双归宿耦合的子VPN）。
o Site-network-access#1 and site-network-access#3 will correspond to the multihoming of subVPN B. A PE-diverse constraint is required between them.
o 站点网络访问#1和站点网络访问#3将对应于子VPN B的多归属。它们之间需要PE多样性约束。
o Site-network-access#2 and site-network-access#4 will correspond to the multihoming of subVPN C. A PE-diverse constraint is required between them.
o 站点网络访问#2和站点网络访问#4将对应于子VPN C的多归属。它们之间需要PE多样性约束。
o To ensure proper usage of the same bearer for the subVPN, site-network-access#1 and site-network-access#2 must share the same bearer as site-network-access#3 and site-network-access#4.
o 为确保子VPN正确使用同一承载，站点网络访问#1和站点网络访问#2必须与站点网络访问#3和站点网络访问#4共享同一承载。
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>2</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>3</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>3</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>4</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNB</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
<site-network-access>
<site-network-access-id>4</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>dualhomed-2</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>dualhomed-1</group-id>
</group>
</target>
</constraint>
<constraint>
<constraint-type>same-bearer</constraint-type>
<target>
<group>
<group-id>dualhomed-2</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<vpn-attachment>
<vpn-id>VPNC</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
</site>
The route distinguisher (RD) is a critical parameter of PE-based L3VPNs as described in [RFC4364] that provides the ability to distinguish common addressing plans in different VPNs. As for route targets (RTs), a management system is expected to allocate a VRF on the target PE and an RD for this VRF.
如[RFC4364]所述，路由识别器（RD）是基于PE的L3VPN的一个关键参数，它提供了区分不同VPN中常见寻址计划的能力。对于路由目标（RTs），管理系统应在目标PE上分配一个VRF，并为此VRF分配一个RD。
If a VRF already exists on the target PE and the VRF fulfills the connectivity constraints for the site, there is no need to recreate another VRF, and the site MAY be meshed within this existing VRF. How the management system checks that an existing VRF fulfills the connectivity constraints for a site is out of scope for this document.
如果目标PE上已经存在VRF，并且VRF满足站点的连接约束，则无需重新创建另一个VRF，并且站点可以在该现有VRF内啮合。管理系统如何检查现有VRF是否满足站点的连接约束超出了本文件的范围。
If no such VRF exists on the target PE, the management system has to initiate the creation of a new VRF on the target PE and has to allocate a new RD for this new VRF.
如果目标PE上不存在此类VRF，管理系统必须在目标PE上启动新VRF的创建，并且必须为此新VRF分配新RD。
The management system MAY apply a per-VPN or per-VRF allocation policy for the RD, depending on the SP's policy. In a per-VPN allocation policy, all VRFs (dispatched on multiple PEs) within a VPN will share the same RD value. In a per-VRF model, all VRFs should always have a unique RD value. Some other allocation policies are also possible, and this document does not restrict the allocation policies to be used.
根据SP的策略，管理系统可为RD应用每VPN或每VRF分配策略。在每VPN分配策略中，VPN内的所有VRF（在多个PE上调度）将共享相同的RD值。在每个VRF模型中，所有VRF应始终具有唯一的RD值。也可以使用其他一些分配策略，本文档不限制要使用的分配策略。
The allocation of RDs MAY be done in the same way as RTs. The examples provided in Section 6.2.1.1 could be reused in this scenario.
RDs的分配可采用与RTs相同的方式进行。第6.2.1.1节中提供的示例可在此场景中重复使用。
Note that an SP MAY configure a target PE for an automated allocation of RDs. In this case, there will be no need for any backend system to allocate an RD value.
请注意，SP可能会为RDs的自动分配配置目标PE。在这种情况下，任何后端系统都不需要分配RD值。
A site may be multihomed, meaning that it has multiple site-network-access points. Placement constraints defined in previous sections will help ensure physical diversity.
一个站点可以是多址的，这意味着它有多个站点网络接入点。前几节中定义的布局约束将有助于确保物理多样性。
When the site-network-accesses are placed on the network, a customer may want to use a particular routing policy on those accesses.
当站点网络访问置于网络上时，客户可能希望在这些访问上使用特定的路由策略。
The "site-network-access/availability" container defines parameters for site redundancy. The "access-priority" leaf defines a preference for a particular access. This preference is used to model load-balancing or primary/backup scenarios. The higher the access-priority value, the higher the preference will be.
“站点网络访问/可用性”容器定义站点冗余的参数。“访问优先级”叶定义特定访问的首选项。此首选项用于为负载平衡或主/备份场景建模。访问优先级值越高，首选项越高。
The figure below describes how the access-priority attribute can be used.
下图描述了如何使用访问优先级属性。
Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
| |
| access-priority 1 access-priority 1 |
|--- CE1 ------- PE1 PE3 --------- CE3 --- |
| |
| |
|--- CE2 ------- PE2 PE4 --------- CE4 --- |
| access-priority 2 access-priority 1 |
Hub#1 LAN (Primary/backup) Hub#2 LAN (Load-sharing)
| |
| access-priority 1 access-priority 1 |
|--- CE1 ------- PE1 PE3 --------- CE3 --- |
| |
| |
|--- CE2 ------- PE2 PE4 --------- CE4 --- |
| access-priority 2 access-priority 1 |
PE5
|
|
|
CE5
|
Spoke#1 site (Single-homed)
PE5
|
|
|
CE5
|
Spoke#1 site (Single-homed)
In the figure above, Hub#2 requires load-sharing, so all the site-network-accesses must use the same access-priority value. On the other hand, as Hub#1 requires a primary site-network-access and a backup site-network-access, a higher access-priority setting will be configured on the primary site-network-access.
在上图中，Hub#2需要负载共享，因此所有站点网络访问必须使用相同的访问优先级值。另一方面，由于Hub#1需要主站点网络访问和备份站点网络访问，将在主站点网络访问上配置更高的访问优先级设置。
Scenarios that are more complex can be modeled. Let's consider a Hub site with five accesses to the network (A1,A2,A3,A4,A5). The customer wants to load-share its traffic on A1,A2 in the nominal situation. If A1 and A2 fail, the customer wants to load-share its traffic on A3 and A4; finally, if A1 to A4 are down, he wants to use A5. We can model this easily by configuring the following access-priority values: A1=100, A2=100, A3=50, A4=50, A5=10.
可以对更复杂的场景进行建模。让我们考虑一个有五个访问网络的集线器站点（A1，A2，A3，A4，A5）。客户希望在正常情况下在A1、A2上加载和共享其流量。如果A1和A2失败，客户希望在A3和A4上加载共享其流量；最后，如果A1到A4下降，他想使用A5。我们可以通过配置以下访问优先级值来轻松建模：A1=100、A2=100、A3=50、A4=50、A5=10。
The access-priority scenario has some limitations. An access-priority scenario like the previous one with five accesses but with the constraint of having traffic load-shared between A3 and A4 in the case where A1 OR A2 is down is not achievable. But the authors believe that using the access-priority attribute will cover most of the deployment use cases and that the model can still be extended via augmentation to support additional use cases.
访问优先级场景有一些限制。与前一种具有五个访问的访问优先级场景类似，但在A1或A2停机的情况下，A3和A4之间共享流量负载的约束是不可能实现的。但是作者相信，使用访问优先级属性将覆盖大多数部署用例，并且该模型仍然可以通过扩展来支持其他用例。
The service model supports the ability to protect the traffic for a site. Such protection provides a better level of availability in multihoming scenarios by, for example, using local-repair techniques in case of failures. The associated level of service guarantee would be based on an agreement between the customer and the SP and is out of scope for this document.
服务模型支持保护站点流量的能力。这种保护在多主场景中提供了更好的可用性级别，例如，在出现故障时使用本地修复技术。相关的服务水平保证将基于客户和SP之间的协议，不在本文件的范围内。
Site#1 Site#2
CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
| | |
| | |
CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
/
/
CE5 ----+
Site#3
Site#1 Site#2
CE1 ----- PE1 -- P1 P3 -- PE3 ---- CE3
| | |
| | |
CE2 ----- PE2 -- P2 P4 -- PE4 ---- CE4
/
/
CE5 ----+
Site#3
In the figure above, we consider an IP VPN service with three sites, including two dual-homed sites (Site#1 and Site#2). For dual-homed sites, we consider PE1-CE1 and PE3-CE3 as primary and PE2-CE2,PE4-CE4 as backup for the example (even if protection also applies to load-sharing scenarios).
在上面的图中，我们考虑了三个站点的IP VPN服务，包括两个双归属站点（站点1和站点2）。对于双归属站点，我们认为PE1-CE1和PE3-CE3为主，PE2-CE2，PE4-CE4作为示例的备份（即使保护也适用于负载共享方案）。
In order to protect Site#2 against a failure, a user may set the "traffic-protection/enabled" leaf to true for Site#2. How the traffic protection will be implemented is out of scope for this document. However, in such a case, we could consider traffic coming from a remote site (Site#1 or Site#3), where the primary path would use PE3 as the egress PE. PE3 may have preprogrammed a backup forwarding entry pointing to the backup path (through PE4-CE4) for all prefixes going through the PE3-CE3 link. How the backup path is computed is out of scope for this document. When the PE3-CE3 link fails, traffic is still received by PE3, but PE3 automatically switches traffic to the backup entry; the path will therefore be PE1-P1-(...)-P3-PE3-PE4-CE4 until the remote PEs reconverge and use PE4 as the egress PE.
为了防止站点2发生故障，用户可以将站点2的“流量保护/启用”叶设置为true。如何实施交通保护超出了本文件的范围。然而，在这种情况下，我们可以考虑来自远程站点（站点α1或站点3）的流量，其中主路径将使用PE3作为出口PE。PE3可能已经为通过PE3-CE3链路的所有前缀预先编程了一个指向备份路径（通过PE4-CE4）的备份转发条目。如何计算备份路径超出了本文档的范围。当PE3-CE3链路失效时，PE3仍能接收到流量，但PE3会自动将流量切换到备份条目；因此，路径将为PE1-P1-（…）-P3-PE3-PE4-CE4，直到远程PE重新会聚并使用PE4作为出口PE。
The "security" container defines customer-specific security parameters for the site. The security options supported in the model are limited but may be extended via augmentation.
“安全”容器为站点定义特定于客户的安全参数。模型中支持的安全选项是有限的，但可以通过扩展进行扩展。
The current model does not support any authentication parameters for the site connection, but such parameters may be added in the "authentication" container through augmentation.
当前模型不支持站点连接的任何身份验证参数，但是可以通过扩展将这些参数添加到“身份验证”容器中。
Traffic encryption can be requested on the connection. It may be performed at Layer 2 or Layer 3 by selecting the appropriate enumeration in the "layer" leaf. For example, an SP may use IPsec when a customer requests Layer 3 encryption. The encryption profile can be SP defined or customer specific.
可以在连接上请求流量加密。通过在“层”叶中选择适当的枚举，可以在第2层或第3层执行。例如，当客户请求第3层加密时，SP可能会使用IPsec。加密配置文件可以是SP定义的，也可以是特定于客户的。
When an SP profile is used and a key (e.g., a pre-shared key) is allocated by the provider to be used by a customer, the SP should provide a way to communicate the key in a secured way to the customer.
当使用SP配置文件且提供商分配密钥（例如，预共享密钥）供客户使用时，SP应提供一种以安全方式向客户传达密钥的方法。
When a customer profile is used, the model supports only a pre-shared key for authentication, with the pre-shared key provided through the NETCONF or RESTCONF request. A secure channel must be used to ensure that the pre-shared key cannot be intercepted.
使用客户概要文件时，该模型仅支持预共享密钥进行身份验证，预共享密钥通过NETCONF或RESTCONF请求提供。必须使用安全通道来确保预共享密钥不会被截获。
For security reasons, it may be necessary for the customer to change the pre-shared key on a regular basis. To perform a key change, the user can ask the SP to change the pre-shared key by submitting a new pre-shared key for the site configuration (as shown below). This mechanism might not be hitless.
出于安全原因，客户可能需要定期更改预共享密钥。要执行密钥更改，用户可以要求SP通过为站点配置提交新的预共享密钥来更改预共享密钥（如下所示）。这种机制可能不是无故障的。
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<security>
<encryption-profile>
<preshared-key>MY_NEW_KEY</preshared-key>
</encryption-profile>
</security>
</site-network-access>
</site-network-accesses>
</site>
<site>
<site-id>SITE1</site-id>
<site-network-accesses>
<site-network-access>
<site-network-access-id>1</site-network-access-id>
<security>
<encryption-profile>
<preshared-key>MY_NEW_KEY</preshared-key>
</encryption-profile>
</security>
</site-network-access>
</site-network-accesses>
</site>
A hitless key-change mechanism may be added through augmentation.
可以通过扩充添加无故障密钥更改机制。
Other key-management methodologies may be added through augmentation. A "pki" container, which is empty, has been created to help with support of PKI through augmentation.
其他关键管理方法可以通过扩充来添加。创建了一个空的“pki”容器，通过扩展来帮助支持pki。
The model proposes three types of common management options:
该模型提出了三种常见的管理选项：
o provider-managed: The CE router is managed only by the provider. In this model, the responsibility boundary between the SP and the customer is between the CE and the customer network.
o 提供商管理：CE路由器仅由提供商管理。在该模型中，SP和客户之间的责任边界是CE和客户网络之间的。
o customer-managed: The CE router is managed only by the customer. In this model, the responsibility boundary between the SP and the customer is between the PE and the CE.
o 客户管理：CE路由器仅由客户管理。在此模型中，SP和客户之间的责任边界是PE和CE之间的。
o co-managed: The CE router is primarily managed by the provider; in addition, the SP allows customers to access the CE for configuration/monitoring purposes. In the co-managed mode, the responsibility boundary is the same as the responsibility boundary for the provider-managed model.
o 共同管理：CE路由器主要由提供商管理；此外，SP允许客户访问CE进行配置/监控。在共同管理模式下，责任边界与提供者管理模型的责任边界相同。
Based on the management model, different security options MAY be derived.
根据管理模型，可以导出不同的安全选项。
In the co-managed case, the model proposes some options to define the management address family (IPv4 or IPv6) and the associated management address.
在共同管理的情况下，该模型提出了一些选项来定义管理地址系列（IPv4或IPv6）和关联的管理地址。
"routing-protocol" defines which routing protocol must be activated between the provider and the customer router. The current model supports the following settings: bgp, rip, ospf, static, direct, and vrrp.
“路由协议”定义了提供商和客户路由器之间必须激活的路由协议。当前型号支持以下设置：bgp、rip、ospf、静态、直接和vrrp。
The routing protocol defined applies at the provider-to-customer boundary. Depending on how the management model is administered, it may apply to the PE-CE boundary or the CE-to-customer boundary. In the case of a customer-managed site, the routing protocol defined will be activated between the PE and the CE router managed by the customer. In the case of a provider-managed site, the routing protocol defined will be activated between the CE managed by the SP and the router or LAN belonging to the customer. In this case, we expect the PE-CE routing to be configured based on the SP's rules, as both are managed by the same entity.
定义的路由协议适用于提供商到客户的边界。根据管理模式的管理方式，它可能适用于PE-CE边界或CE到客户边界。对于客户管理的站点，定义的路由协议将在客户管理的PE和CE路由器之间激活。对于提供商管理的站点，将在SP管理的CE和属于客户的路由器或LAN之间激活定义的路由协议。在这种情况下，我们希望根据SP的规则配置PE-CE路由，因为两者都由同一实体管理。
Rtg protocol
192.0.2.0/24 ----- CE ----------------- PE1
Rtg protocol
192.0.2.0/24 ----- CE ----------------- PE1
Customer-managed site
客户管理站点
Rtg protocol
Customer router ----- CE ----------------- PE1
Rtg protocol
Customer router ----- CE ----------------- PE1
Provider-managed site
提供商管理的站点
All the examples below will refer to a scenario for a customer-managed site.
下面的所有示例都涉及客户管理站点的场景。
All routing protocol types support dual stack by using the "address-family" leaf-list.
通过使用“地址族”叶列表，所有路由协议类型都支持双堆栈。
Example of dual stack using the same routing protocol:
使用相同路由协议的双堆栈示例：
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</static>
</routing-protocol>
</routing-protocols>
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</static>
</routing-protocol>
</routing-protocols>
Example of dual stack using two different routing protocols:
使用两种不同路由协议的双堆栈示例：
<routing-protocols>
<routing-protocol>
<type>rip</type>
<rip>
<address-family>ipv4</address-family>
</rip>
</routing-protocol>
<routing-protocol>
<type>ospf</type>
<ospf>
<address-family>ipv6</address-family>
</ospf>
</routing-protocol>
</routing-protocols>
<routing-protocols>
<routing-protocol>
<type>rip</type>
<rip>
<address-family>ipv4</address-family>
</rip>
</routing-protocol>
<routing-protocol>
<type>ospf</type>
<ospf>
<address-family>ipv6</address-family>
</ospf>
</routing-protocol>
</routing-protocols>
The routing protocol type "direct" SHOULD be used when a customer LAN is directly connected to the provider network and must be advertised in the IP VPN.
当客户LAN直接连接到提供商网络时，应使用路由协议类型“direct”，并且必须在IP VPN中公布。
LAN attached directly to provider network:
直接连接到提供商网络的LAN：
192.0.2.0/24 ----- PE1
192.0.2.0/24 ----- PE1
In this case, the customer has a default route to the PE address.
在这种情况下，客户有一个到PE地址的默认路由。
The routing protocol type "vrrp" SHOULD be used and advertised in the IP VPN when
当需要时，应在IP VPN中使用并公布路由协议类型“vrrp”
o the customer LAN is directly connected to the provider network, and
o 客户LAN直接连接到提供商网络，并且
o LAN redundancy is expected.
o 预计会出现局域网冗余。
LAN attached directly to provider network with LAN redundancy:
通过LAN冗余直接连接到提供商网络的LAN：
192.0.2.0/24 ------ PE1
|
+--- PE2
192.0.2.0/24 ------ PE1
|
+--- PE2
In this case, the customer has a default route to the SP network.
在这种情况下，客户有到SP网络的默认路由。
The routing protocol type "static" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. In this case, the static routes give next hops (nh) to the CE and to the PE. The customer has a default route to the SP network.
当客户LAN通过CE路由器连接到提供商网络时，可以使用路由协议类型“静态”，并且必须在IP VPN中公布。在这种情况下，静态路由向CE和PE提供下一跳（nh）。客户有到SP网络的默认路由。
Static rtg
192.0.2.0/24 ------ CE -------------- PE
| |
| Static route 192.0.2.0/24 nh CE
Static route 0.0.0.0/0 nh PE
Static rtg
192.0.2.0/24 ------ CE -------------- PE
| |
| Static route 192.0.2.0/24 nh CE
Static route 0.0.0.0/0 nh PE
The routing protocol type "rip" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN. For IPv4, the model assumes that RIP version 2 is used.
当客户LAN通过CE路由器连接到提供商网络时，可以使用路由协议类型“rip”，并且必须在IP VPN中公布。对于IPv4，模型假定使用RIP版本2。
In the case of dual-stack routing requested through this model, the management system will be responsible for configuring RIP (including the correct version number) and associated address families on network elements.
对于通过该模型请求的双栈路由，管理系统将负责配置RIP（包括正确的版本号）和网元上的相关地址族。
RIP rtg
192.0.2.0/24 ------ CE -------------- PE
RIP rtg
192.0.2.0/24 ------ CE -------------- PE
The routing protocol type "ospf" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN.
当客户LAN通过CE路由器连接到提供商网络时，可以使用路由协议类型“ospf”，并且必须在IP VPN中公布。
It can be used to extend an existing OSPF network and interconnect different areas. See [RFC4577] for more details.
它可以用来扩展现有的OSPF网络并互连不同的区域。有关更多详细信息，请参阅[RFC4577]。
+---------------------+
| |
OSPF | | OSPF
area 1 | | area 2
(OSPF | | (OSPF
area 1) --- CE ---------- PE PE ----- CE --- area 2)
| |
+---------------------+
+---------------------+
| |
OSPF | | OSPF
area 1 | | area 2
(OSPF | | (OSPF
area 1) --- CE ---------- PE PE ----- CE --- area 2)
| |
+---------------------+
The model also proposes an option to create an OSPF sham link between two sites sharing the same area and having a backdoor link. The sham link is created by referencing the target site sharing the same OSPF area. The management system will be responsible for checking to see if there is already a sham link configured for this VPN and area between the same pair of PEs. If there is no existing sham link, the management system will provision one. This sham link MAY be reused by other sites.
该模型还提出了在共享同一区域并具有后门链接的两个站点之间创建OSPF假链接的选项。通过引用共享相同OSPF区域的目标站点来创建假链接。管理系统将负责检查是否已经为此VPN和同一对PE之间的区域配置了假链路。如果没有现有的假链接，管理系统将提供一个。此假链接可由其他站点重复使用。
+------------------------+
| |
| |
| PE (--sham link--)PE |
| | | |
+----|----------------|--+
| OSPF area 1 | OSPF area 1
| |
CE1 CE2
| |
(OSPF area 1) (OSPF area 1)
| |
+----------------+
+------------------------+
| |
| |
| PE (--sham link--)PE |
| | | |
+----|----------------|--+
| OSPF area 1 | OSPF area 1
| |
CE1 CE2
| |
(OSPF area 1) (OSPF area 1)
| |
+----------------+
Regarding dual-stack support, the user MAY specify both IPv4 and IPv6 address families, if both protocols should be routed through OSPF. As OSPF uses separate protocol instances for IPv4 and IPv6, the management system will need to configure both OSPF version 2 and OSPF version 3 on the PE-CE link.
关于双栈支持，如果两个协议都应该通过OSPF路由，则用户可以指定IPv4和IPv6地址系列。由于OSPF对IPv4和IPv6使用单独的协议实例，管理系统需要在PE-CE链路上同时配置OSPF版本2和OSPF版本3。
Example of OSPF routing parameters in the service model:
服务模型中的OSPF路由参数示例：
<routing-protocols>
<routing-protocol>
<type>ospf</type>
<ospf>
<area-address>0.0.0.1</area-address>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</ospf>
</routing-protocol>
</routing-protocols>
<routing-protocols>
<routing-protocol>
<type>ospf</type>
<ospf>
<area-address>0.0.0.1</area-address>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</ospf>
</routing-protocol>
</routing-protocols>
Example of PE configuration done by the management system:
管理系统完成的PE配置示例：
router ospf 10 area 0.0.0.1 interface Ethernet0/0 ! router ospfv3 10 area 0.0.0.1 interface Ethernet0/0 !
路由器ospf 10区域0.0.0.1接口以太网0/0！路由器ospfv3 10区域0.0.0.1接口以太网0/0！
The routing protocol type "bgp" MAY be used when a customer LAN is connected to the provider network through a CE router and must be advertised in the IP VPN.
当客户LAN通过CE路由器连接到提供商网络时，可以使用路由协议类型“bgp”，并且必须在IP VPN中公布。
BGP rtg
192.0.2.0/24 ------ CE -------------- PE
BGP rtg
192.0.2.0/24 ------ CE -------------- PE
The session addressing will be derived from connection parameters as well as the SP's knowledge of the addressing plan that is in use.
会话寻址将从连接参数以及SP对正在使用的寻址计划的了解中派生。
In the case of dual-stack access, the user MAY request BGP routing for both IPv4 and IPv6 by specifying both address families. It will be up to the SP and management system to determine how to decline the configuration (two BGP sessions, single, multi-session, etc.).
在双栈访问的情况下，用户可以通过指定两个地址族来请求IPv4和IPv6的BGP路由。SP和管理系统将决定如何拒绝配置（两个BGP会话、单会话、多会话等）。
The service configuration below activates BGP on the PE-CE link for both IPv4 and IPv6.
下面的服务配置在IPv4和IPv6的PE-CE链路上激活BGP。
BGP activation requires the SP to know the address of the customer peer. The "static-address" allocation type for the IP connection MUST be used.
BGP激活要求SP知道客户对等方的地址。必须使用IP连接的“静态地址”分配类型。
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>65000</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>65000</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
Depending on the SP flavor, a management system can divide this service configuration into different flavors, as shown by the following examples.
根据SP风格，管理系统可以将此服务配置划分为不同的风格，如以下示例所示。
Example of PE configuration done by the management system (single IPv4 transport session):
管理系统完成的PE配置示例（单个IPv4传输会话）：
router bgp 100 neighbor 203.0.113.2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out
路由器bgp 100邻居203.0.113.2远程as 65000地址系列ipv4 vrf Cust1邻居203.0.113.2激活地址系列ipv6 vrf Cust1邻居203.0.113.2激活邻居203.0.113.2路由图设置-NH-ipv6输出
Example of PE configuration done by the management system (two sessions):
管理系统完成的PE配置示例（两个会话）：
router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 2001::2 remote-as 65000 address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 2001::2 activate
路由器bgp 100邻居203.0.113.2远程as 65000邻居2001:：2远程as 65000地址系列ipv4 vrf Cust1邻居203.0.113.2激活地址系列ipv6 vrf Cust1邻居2001:：2激活
Example of PE configuration done by the management system (multi-session):
管理系统完成的PE配置示例（多会话）：
router bgp 100 neighbor 203.0.113.2 remote-as 65000 neighbor 203.0.113.2 multisession per-af address-family ipv4 vrf Cust1 neighbor 203.0.113.2 activate address-family ipv6 vrf Cust1 neighbor 203.0.113.2 activate neighbor 203.0.113.2 route-map SET-NH-IPV6 out
路由器bgp 100邻居203.0.113.2远程as 65000邻居203.0.113.2每af地址系列多会话ipv4 vrf Cust1邻居203.0.113.2激活地址系列ipv6 vrf Cust1邻居203.0.113.2激活邻居203.0.113.2路由图集-NH-ipv6输出
The service defines service parameters associated with the site.
该服务定义与站点关联的服务参数。
The service bandwidth refers to the bandwidth requirement between the PE and the CE (WAN link bandwidth). The requested bandwidth is expressed as svc-input-bandwidth and svc-output-bandwidth in bits per second. The input/output direction uses the customer site as a reference: "input bandwidth" means download bandwidth for the site, and "output bandwidth" means upload bandwidth for the site.
服务带宽是指PE和CE之间的带宽需求（WAN链路带宽）。请求的带宽表示为svc输入带宽和svc输出带宽，单位为位/秒。输入/输出方向使用客户站点作为参考：“输入带宽”表示站点的下载带宽，“输出带宽”表示站点的上传带宽。
The service bandwidth is only configurable at the site-network-access level.
服务带宽仅可在站点网络访问级别配置。
Using a different input and output bandwidth will allow the SP to determine if the customer allows for asymmetric bandwidth access, such as ADSL. It can also be used to set rate-limiting in a different way for uploading and downloading on a symmetric bandwidth access.
使用不同的输入和输出带宽将允许SP确定客户是否允许不对称带宽访问，如ADSL。它还可以用于以不同的方式设置速率限制，以便在对称带宽访问上上载和下载。
The bandwidth is a service bandwidth expressed primarily as IP bandwidth, but if the customer enables MPLS for Carriers' Carriers (CsC), this becomes MPLS bandwidth.
带宽是主要表示为IP带宽的服务带宽，但如果客户为运营商的运营商（CsC）启用MPLS，这将成为MPLS带宽。
The model proposes to define QoS parameters in an abstracted way:
该模型建议以抽象的方式定义QoS参数：
o qos-classification-policy: policy that defines a set of ordered rules to classify customer traffic.
o qos分类策略：定义一组有序规则以对客户流量进行分类的策略。
o qos-profile: QoS scheduling profile to be applied.
o qos配置文件：要应用的qos调度配置文件。
QoS classification rules are handled by the "qos-classification-policy" container. The qos-classification-policy container is an ordered list of rules that match a flow or application and set the appropriate target class of service (target-class-id). The user can define the match using an application reference or a flow definition that is more specific (e.g., based on Layer 3 source and destination addresses, Layer 4 ports, and Layer 4 protocol). When a flow definition is used, the user can employ a "target-sites" leaf-list to identify the destination of a flow rather than using destination IP addresses. In such a case, an association between the site abstraction and the IP
QoS分类规则由“QoS分类策略”容器处理。qos分类策略容器是规则的有序列表，这些规则与流或应用程序相匹配，并设置适当的目标服务类（目标类id）。用户可以使用更具体的应用程序引用或流定义（例如，基于第3层源地址和目标地址、第4层端口和第4层协议）来定义匹配。当使用流定义时，用户可以使用“目标站点”叶列表来标识流的目的地，而不是使用目的地IP地址。在这种情况下，站点抽象和IP之间的关联
addresses used by this site must be done dynamically. How this association is done is out of scope for this document; an implementation might not support this criterion and should advertise a deviation in this case. A rule that does not have a match statement is considered a match-all rule. An SP may implement a default terminal classification rule if the customer does not provide it. It will be up to the SP to determine its default target class. The current model defines some applications, but new application identities may be added through augmentation. The exact meaning of each application identity is up to the SP, so it will be necessary for the SP to advise the customer on the usage of application matching.
此站点使用的地址必须动态完成。该关联的实现方式超出了本文件的范围；实现可能不支持此标准，在这种情况下应公布偏差。没有match语句的规则被视为match all规则。如果客户未提供默认的终端分类规则，SP可以实施该规则。SP将决定其默认目标类。当前模型定义了一些应用程序，但是可以通过扩展添加新的应用程序标识。每个应用程序标识的确切含义由SP决定，因此SP有必要就应用程序匹配的使用向客户提供建议。
Where the classification is done depends on the SP's implementation of the service, but classification concerns the flow coming from the customer site and entering the network.
进行分类的位置取决于SP的服务实施情况，但分类涉及来自客户站点和进入网络的流量。
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
Traffic flow
---------->
Traffic flow
---------->
In the figure above, the management system should implement the classification rule:
在上图中，管理体系应执行分类规则：
o in the ingress direction on the PE interface, if the CE is customer-managed.
o 在PE接口上的入口方向，如果CE由客户管理。
o in the ingress direction on the CE interface connected to the customer LAN, if the CE is provider-managed.
o 在连接到客户LAN的CE接口上的入口方向，如果CE由提供商管理。
The figure below describes a sample service description of QoS classification for a site:
下图描述了站点QoS分类的示例服务描述：
<service>
<qos>
<qos-classification-policy>
<rule>
<id>1</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>80</l4-dst-port>
<l4-protocol>tcp</l4-protocol>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>2</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>21</l4-dst-port>
<l4-protocol>tcp</l4-protocol>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>3</id>
<match-application>p2p</match-application>
<target-class-id>DATA3</target-class-id>
</rule>
<rule>
<id>4</id>
<target-class-id>DATA1</target-class-id>
</rule>
</qos-classification-policy>
</qos>
</service>
<service>
<qos>
<qos-classification-policy>
<rule>
<id>1</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>80</l4-dst-port>
<l4-protocol>tcp</l4-protocol>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>2</id>
<match-flow>
<ipv4-src-prefix>192.0.2.0/24</ipv4-src-prefix>
<ipv4-dst-prefix>203.0.113.1/32</ipv4-dst-prefix>
<l4-dst-port>21</l4-dst-port>
<l4-protocol>tcp</l4-protocol>
</match-flow>
<target-class-id>DATA2</target-class-id>
</rule>
<rule>
<id>3</id>
<match-application>p2p</match-application>
<target-class-id>DATA3</target-class-id>
</rule>
<rule>
<id>4</id>
<target-class-id>DATA1</target-class-id>
</rule>
</qos-classification-policy>
</qos>
</service>
In the example above:
在上述示例中：
o HTTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 will be classified in DATA2.
o 来自192.0.2.0/24 LAN、目的地为203.0.113.1/32的HTTP通信量将分类为DATA2。
o FTP traffic from the 192.0.2.0/24 LAN destined for 203.0.113.1/32 will be classified in DATA2.
o 来自192.0.2.0/24 LAN、目的地为203.0.113.1/32的FTP通信量将分类为数据2。
o Peer-to-peer traffic will be classified in DATA3.
o 对等通信量将在数据3中分类。
o All other traffic will be classified in DATA1.
o 所有其他流量将在数据1中分类。
The order of rules is very important. The management system responsible for translating those rules in network element configuration MUST keep the same processing order in network element configuration. The order of rules is defined by the "id" leaf. The lowest id MUST be processed first.
规则的顺序非常重要。负责在网元配置中翻译这些规则的管理系统必须在网元配置中保持相同的处理顺序。规则的顺序由“id”叶定义。必须首先处理最低的id。
The user can choose either a standard profile provided by the operator or a custom profile. The "qos-profile" container defines the traffic-scheduling policy to be used by the SP.
用户可以选择操作员提供的标准配置文件或自定义配置文件。“qos配置文件”容器定义SP要使用的流量调度策略。
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
\ /
qos-profile
Provider network
+-----------------------+
192.0.2.0/24
198.51.100.0/24 ---- CE --------- PE
\ /
qos-profile
In the case of a provider-managed or co-managed connection, the provider should ensure scheduling according to the requested policy in both traffic directions (SP to customer and customer to SP). As an example, a device-scheduling policy may be implemented on both the PE side and the CE side of the WAN link. In the case of a customer-managed connection, the provider is only responsible for ensuring scheduling from the SP network to the customer site. As an example, a device-scheduling policy may be implemented only on the PE side of the WAN link towards the customer.
对于由提供商管理或共同管理的连接，提供商应确保在两个通信方向（SP到客户和客户到SP）上根据请求的策略进行调度。例如，可以在WAN链路的PE侧和CE侧上实现设备调度策略。对于客户管理的连接，提供商仅负责确保从SP网络到客户站点的调度。例如，设备调度策略可以仅在朝向客户的WAN链路的PE侧上实现。
A custom QoS profile is defined as a list of classes of services and associated properties. The properties are:
自定义QoS配置文件定义为服务类和相关属性的列表。这些物业包括：
o rate-limit: used to rate-limit the class of service. The value is expressed as a percentage of the global service bandwidth. When the qos-profile container is implemented on the CE side, svc-output-bandwidth is taken into account as a reference. When it is implemented on the PE side, svc-input-bandwidth is used.
o 费率限制：用于对服务类别进行费率限制。该值表示为全局服务带宽的百分比。当qos配置文件容器在CE端实现时，svc输出带宽将作为参考考虑。在PE端实现时，使用svc输入带宽。
o latency: used to define the latency constraint of the class. The latency constraint can be expressed as the lowest possible latency or a latency boundary expressed in milliseconds. How this latency constraint will be fulfilled is up to the SP's implementation of
o 延迟：用于定义类的延迟约束。延迟约束可以表示为可能的最低延迟或以毫秒为单位的延迟边界。如何满足此延迟约束取决于SP的
the service: a strict priority queuing may be used on the access and in the core network, and/or a low-latency routing configuration may be created for this traffic class.
服务：可在接入和核心网络中使用严格的优先级队列，和/或可为此流量类别创建低延迟路由配置。
o jitter: used to define the jitter constraint of the class. The jitter constraint can be expressed as the lowest possible jitter or a jitter boundary expressed in microseconds. How this jitter constraint will be fulfilled is up to the SP's implementation of the service: a strict priority queuing may be used on the access and in the core network, and/or a jitter-aware routing configuration may be created for this traffic class.
o 抖动：用于定义类的抖动约束。抖动约束可以表示为最低可能抖动或以微秒表示的抖动边界。如何满足该抖动约束取决于SP对服务的实现：可在接入和核心网络中使用严格的优先级队列，和/或可为此流量类别创建抖动感知路由配置。
o bandwidth: used to define a guaranteed amount of bandwidth for the class of service. It is expressed as a percentage. The "guaranteed-bw-percent" parameter uses available bandwidth as a reference. When the qos-profile container is implemented on the CE side, svc-output-bandwidth is taken into account as a reference. When it is implemented on the PE side, svc-input-bandwidth is used. By default, the bandwidth reservation is only guaranteed at the access level. The user can use the "end-to-end" leaf to request an end-to-end bandwidth reservation, including across the MPLS transport network. (In other words, the SP will activate something in the MPLS core to ensure that the bandwidth request from the customer will be fulfilled by the MPLS core as well.) How this is done (e.g., RSVP reservation, controller reservation) is out of scope for this document.
o 带宽：用于定义服务类别的带宽保证量。它以百分比表示。“保证bw百分比”参数使用可用带宽作为参考。当qos配置文件容器在CE端实现时，svc输出带宽将作为参考考虑。在PE端实现时，使用svc输入带宽。默认情况下，带宽保留仅在访问级别得到保证。用户可以使用“端到端”叶请求端到端带宽预留，包括通过MPLS传输网络。（换句话说，SP将激活MPLS核心中的某些内容，以确保来自客户的带宽请求也将由MPLS核心完成。）如何完成（例如，RSVP保留、控制器保留）超出本文档的范围。
Some constraints may not be offered by an SP; in this case, a deviation should be advertised. In addition, due to network conditions, some constraints may not be completely fulfilled by the SP; in this case, the SP should advise the customer about the limitations. How this communication is done is out of scope for this document.
SP可能不提供某些约束条件；在这种情况下，应公布偏差。此外，由于网络条件，SP可能无法完全满足某些约束条件；在这种情况下，SP应告知客户限制。如何进行沟通超出了本文件的范围。
Example of service configuration using a standard QoS profile:
使用标准QoS配置文件的服务配置示例：
<site-network-access>
<site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos>
<qos-profile>
<profile>PLATINUM</profile>
</qos-profile>
</qos>
</service>
<site-network-access>
<site-network-access-id>1245HRTFGJGJ154654</site-network-access-id>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos>
<qos-profile>
<profile>PLATINUM</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
<site-network-access>
<site-network-access-id>555555AAAA2344</site-network-access-id>
<service>
<svc-input-bandwidth>2000000</svc-input-bandwidth>
<svc-output-bandwidth>2000000</svc-output-bandwidth>
<qos>
<qos-profile>
<profile>GOLD</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
</site-network-access>
<site-network-access>
<site-network-access-id>555555AAAA2344</site-network-access-id>
<service>
<svc-input-bandwidth>2000000</svc-input-bandwidth>
<svc-output-bandwidth>2000000</svc-output-bandwidth>
<qos>
<qos-profile>
<profile>GOLD</profile>
</qos-profile>
</qos>
</service>
</site-network-access>
Example of service configuration using a custom QoS profile:
使用自定义QoS配置文件的服务配置示例：
<site-network-access>
<site-network-access-id>Site1</site-network-access-id>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos>
<qos-profile>
<classes>
<class>
<class-id>REAL_TIME</class-id>
<rate-limit>10</rate-limit>
<latency>
<use-lowest-latency/>
</latency>
</class>
<class>
<class-id>DATA1</class-id>
<latency>
<latency-boundary>70</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</bandwidth>
</class>
<class>
<class-id>DATA2</class-id>
<latency>
<latency-boundary>200</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>5</guaranteed-bw-percent>
<end-to-end/>
<site-network-access>
<site-network-access-id>Site1</site-network-access-id>
<service>
<svc-input-bandwidth>100000000</svc-input-bandwidth>
<svc-output-bandwidth>100000000</svc-output-bandwidth>
<qos>
<qos-profile>
<classes>
<class>
<class-id>REAL_TIME</class-id>
<rate-limit>10</rate-limit>
<latency>
<use-lowest-latency/>
</latency>
</class>
<class>
<class-id>DATA1</class-id>
<latency>
<latency-boundary>70</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>80</guaranteed-bw-percent>
</bandwidth>
</class>
<class>
<class-id>DATA2</class-id>
<latency>
<latency-boundary>200</latency-boundary>
</latency>
<bandwidth>
<guaranteed-bw-percent>5</guaranteed-bw-percent>
<end-to-end/>
</bandwidth>
</class>
</classes>
</qos-profile>
</qos>
</service>
</site-network-access>
</bandwidth>
</class>
</classes>
</qos-profile>
</qos>
</service>
</site-network-access>
The custom QoS profile for Site1 defines a REAL_TIME class with a latency constraint expressed as the lowest possible latency. It also defines two data classes -- DATA1 and DATA2. The two classes express a latency boundary constraint as well as a bandwidth reservation, as the REAL_TIME class is rate-limited to 10% of the service bandwidth (10% of 100 Mbps = 10 Mbps). In cases where congestion occurs, the REAL_TIME traffic can go up to 10 Mbps (let's assume that only 5 Mbps are consumed). DATA1 and DATA2 will share the remaining bandwidth (95 Mbps) according to their percentage. So, the DATA1 class will be served with at least 76 Mbps of bandwidth, while the DATA2 class will be served with at least 4.75 Mbps. The latency boundary information of the data class may help the SP define a specific buffer tuning or a specific routing within the network. The maximum percentage to be used is not limited by this model but MUST be limited by the management system according to the policies authorized by the SP.
Site1的自定义QoS配置文件定义了一个实时类，其延迟约束表示为可能的最低延迟。它还定义了两个数据类——DATA1和DATA2。这两个类表示延迟边界约束和带宽保留，因为实时类的速率限制为服务带宽的10%（100 Mbps的10%=10 Mbps）。在发生拥塞的情况下，实时通信量可以达到10 Mbps（假设仅消耗5 Mbps）。DATA1和DATA2将根据其百分比共享剩余带宽（95 Mbps）。因此，DATA1类将以至少76 Mbps的带宽提供服务，而DATA2类将以至少4.75 Mbps的带宽提供服务。数据类的延迟边界信息可能有助于SP在网络中定义特定的缓冲区调整或特定路由。要使用的最大百分比不受此模型的限制，但必须由管理系统根据SP授权的策略进行限制。
The "multicast" container defines the type of site in the customer multicast service topology: source, receiver, or both. These parameters will help the management system optimize the multicast service. Users can also define the type of multicast relationship with the customer: router (requires a protocol such as PIM), host (IGMP or MLD), or both. An address family (IPv4, IPv6, or both) can also be defined.
“多播”容器定义客户多播服务拓扑中的站点类型：源、接收器或两者。这些参数将帮助管理系统优化多播服务。用户还可以定义与客户的多播关系类型：路由器（需要PIM等协议）、主机（IGMP或MLD），或两者兼而有之。还可以定义地址系列（IPv4、IPv6或两者）。
In the case of CsC [RFC4364], a customer may want to build an MPLS service using an IP VPN to carry its traffic.
在CsC[RFC4364]的情况下，客户可能希望使用IP VPN构建MPLS服务以承载其流量。
LAN customer1
|
|
CE1
|
| -------------
(vrf_cust1)
CE1_ISP1
| ISP1 POP
| MPLS link
| -------------
|
(vrf ISP1)
PE1
LAN customer1
|
|
CE1
|
| -------------
(vrf_cust1)
CE1_ISP1
| ISP1 POP
| MPLS link
| -------------
|
(vrf ISP1)
PE1
(...) Provider backbone
（…）提供程序主干
PE2
(vrf ISP1)
|
| ------------
|
| MPLS link
| ISP1 POP
CE2_ISP1
(vrf_cust1)
| ------------
|
CE2
|
LAN customer1
PE2
(vrf ISP1)
|
| ------------
|
| MPLS link
| ISP1 POP
CE2_ISP1
(vrf_cust1)
| ------------
|
CE2
|
LAN customer1
In the figure above, ISP1 resells an IP VPN service but has no core network infrastructure between its POPs. ISP1 uses an IP VPN as the core network infrastructure (belonging to another provider) between its POPs.
在上图中，ISP1转售IP VPN服务，但其POP之间没有核心网络基础设施。ISP1使用IP VPN作为其POP之间的核心网络基础设施（属于另一个提供商）。
In order to support CsC, the VPN service must indicate MPLS support by setting the "carrierscarrier" leaf to true in the vpn-service list. The link between CE1_ISP1/PE1 and CE2_ISP1/PE2 must also run an MPLS signalling protocol. This configuration is done at the site level.
为了支持CsC，VPN服务必须通过在VPN服务列表中将“CarrierCarrier”叶设置为true来指示MPLS支持。CE1_ISP1/PE1和CE2_ISP1/PE2之间的链路也必须运行MPLS信令协议。此配置在站点级别完成。
In the proposed model, LDP or BGP can be used as the MPLS signalling protocol. In the case of LDP, an IGP routing protocol MUST also be activated. In the case of BGP signalling, BGP MUST also be configured as the routing protocol.
在该模型中，LDP或BGP可以用作MPLS信令协议。对于LDP，还必须激活IGP路由协议。对于BGP信令，BGP也必须配置为路由协议。
If CsC is enabled, the requested "svc-mtu" leaf will refer to the MPLS MTU and not to the IP MTU.
如果启用了CsC，则请求的“svc mtu”叶将引用MPLS mtu，而不是IP mtu。
The service model sometimes refers to external information through identifiers. As an example, to order a cloud-access to a particular cloud service provider (CSP), the model uses an identifier to refer to the targeted CSP. If a customer is directly using this service model as an API (through REST or NETCONF, for example) to order a particular service, the SP should provide a list of authorized identifiers. In the case of cloud-access, the SP will provide the associated identifiers for each available CSP. The same applies to other identifiers, such as std-qos-profile, OAM profile-name, and provider-profile for encryption.
服务模型有时通过标识符引用外部信息。例如，为了向特定的云服务提供商（CSP）订购云访问，模型使用一个标识符来引用目标CSP。如果客户直接使用此服务模型作为API（例如通过REST或NETCONF）订购特定服务，SP应提供授权标识符列表。在云访问的情况下，SP将为每个可用的CSP提供相关的标识符。这同样适用于其他标识符，例如std qos配置文件、OAM配置文件名称和加密的提供者配置文件。
How an SP provides the meanings of those identifiers to the customer is out of scope for this document.
SP如何向客户提供这些标识符的含义超出了本文档的范围。
An autonomous system (AS) is a single network or group of networks that is controlled by a common system administration group and that uses a single, clearly defined routing protocol. In some cases, VPNs need to span different ASes in different geographic areas or span different SPs. The connection between ASes is established by the SPs and is seamless to the customer. Examples include
自治系统（AS）是由公共系统管理组控制的单个网络或网络组，并使用单个、明确定义的路由协议。在某些情况下，VPN需要跨越不同地理区域的不同ASE或跨越不同SP。ASes之间的连接由SPs建立，并与客户无缝连接。例子包括
o a partnership between SPs (e.g., carrier, cloud) to extend their VPN service seamlessly.
o SP（如运营商、云）之间的合作关系，以无缝扩展其VPN服务。
o an internal administrative boundary within a single SP (e.g., backhaul versus core versus data center).
o 单个SP内的内部管理边界（例如，回程与核心与数据中心）。
NNIs (network-to-network interfaces) have to be defined to extend the VPNs across multiple ASes.
必须定义NNI（网络到网络接口），以便跨多个ASE扩展VPN。
[RFC4364] defines multiple flavors of VPN NNI implementations. Each implementation has pros and cons; this topic is outside the scope of this document. For example, in an Inter-AS option A, autonomous system border router (ASBR) peers are connected by multiple interfaces with at least one of those interfaces spanning the two ASes while being present in the same VPN. In order for these ASBRs to signal unlabeled IP prefixes, they associate each interface with a VPN routing and forwarding (VRF) instance and a Border Gateway Protocol (BGP) session. As a result, traffic between the back-to-back VRFs is IP. In this scenario, the VPNs are isolated from each other, and because the traffic is IP, QoS mechanisms that operate on IP traffic can be applied to achieve customer service level agreements (SLAs).
[RFC4364]定义了多种类型的VPN NNI实现。每种实施都有利弊；本主题不在本文档的范围内。例如，在Inter-AS选项A中，自治系统边界路由器（ASBR）对等点通过多个接口连接，其中至少一个接口跨越两个AS，同时存在于同一VPN中。为了让这些ASBR向未标记的IP前缀发送信号，它们将每个接口与VPN路由和转发（VRF）实例和边界网关协议（BGP）会话相关联。因此，背对背VRF之间的通信量为IP。在这种情况下，VPN彼此隔离，因为流量是IP，可以应用在IP流量上运行的QoS机制来实现客户服务级别协议（SLA）。
-------- -------------- -----------
/ \ / \ / \
| Cloud | | | | |
| Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | |
\ / | | \ /
-------- | | -----------
| |
-------- | My network | -----------
/ \ | | / \
| Cloud | | | | |
| Provider |-----NNI-----| |---NNI---| L3VPN |
| #2 | | | | Partner |
\ / | | | |
-------- | | | |
\ / | |
-------------- \ /
| -----------
|
NNI
|
|
-------------------
/ \
| |
| |
| |
| L3VPN Partner |
| |
\ /
-------------------
-------- -------------- -----------
/ \ / \ / \
| Cloud | | | | |
| Provider |-----NNI-----| |----NNI---| Data Center |
| #1 | | | | |
\ / | | \ /
-------- | | -----------
| |
-------- | My network | -----------
/ \ | | / \
| Cloud | | | | |
| Provider |-----NNI-----| |---NNI---| L3VPN |
| #2 | | | | Partner |
\ / | | | |
-------- | | | |
\ / | |
-------------- \ /
| -----------
|
NNI
|
|
-------------------
/ \
| |
| |
| |
| L3VPN Partner |
| |
\ /
-------------------
The figure above describes an SP network called "My network" that has several NNIs. This network uses NNIs to:
上图描述了一个名为“我的网络”的SP网络，该网络具有多个NNI。该网络使用NNI来：
o increase its footprint by relying on L3VPN partners.
o 通过依赖L3VPN合作伙伴来扩大其业务范围。
o connect its own data center services to the customer IP VPN.
o 将其自己的数据中心服务连接到客户IP VPN。
o enable the customer to access its private resources located in a private cloud owned by some CSPs.
o 使客户能够访问其位于某些CSP拥有的私有云中的私有资源。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + (VRF1)---(VPN1)----(VRF1) + |
| + ASBR + + ASBR + |
| + (VRF2)---(VPN2)----(VRF2) + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
In option A, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. A VPN connection -- physical or logical (on top of physical) -- is created for each VPN that needs to cross the AS boundary, thus providing a back-to-back VRF model.
在选项A中，两个ASE通过ASBR上的物理链路相互连接。出于弹性目的，ASE之间可能存在多个物理连接。为每个需要跨越AS边界的VPN创建一个VPN连接——物理连接或逻辑连接（位于物理连接之上），从而提供一个背对背的VRF模型。
From a service model's perspective, this VPN connection can be seen as a site. Let's say that AS B wants to extend some VPN connections for VPN C on AS A. The administrator of AS B can use this service model to order a site on AS A. All connection scenarios could be
从服务模型的角度来看，此VPN连接可以看作是一个站点。假设AS B希望在AS A上扩展VPN C的一些VPN连接。AS B的管理员可以使用此服务模型在AS A上订购站点。所有连接方案都可以
realized using the features of the current model. As an example, the figure above shows two physical connections that have logical connections per VPN overlaid on them. This could be seen as a dual-homed subVPN scenario. Also, the administrator of AS B will be able to choose the appropriate routing protocol (e.g., E-BGP) to dynamically exchange routes between ASes.
使用当前模型的功能实现。作为一个示例，上图显示了两个物理连接，每个VPN的逻辑连接都覆盖在它们上面。这可以看作是一个双主subVPN场景。此外，AS B的管理员将能够选择适当的路由协议（例如，e-BGP）在AS之间动态交换路由。
This document assumes that the option A NNI flavor SHOULD reuse the existing VPN site modeling.
本文档假设选项A NNI风格应重用现有VPN站点建模。
Example: a customer wants its CSP A to attach its virtual network N to an existing IP VPN (VPN1) that he has from L3VPN SP B.
示例：客户希望其CSP a将其虚拟网络N连接到他从L3VPN SP B获得的现有IP VPN（VPN1）。
CSP A L3VPN SP B
CSP A L3VPN SP B
----------------- -------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +_________+ + | Site#1
| |--------(VRF1)---(VPN1)--(VRF1)+ |
| | + ASBR + + ASBR + |
| | + +_________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / \ /
----------------- -------------------
|
|
VPN1
Site#4
----------------- -------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +_________+ + | Site#1
| |--------(VRF1)---(VPN1)--(VRF1)+ |
| | + ASBR + + ASBR + |
| | + +_________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / \ /
----------------- -------------------
|
|
VPN1
Site#4
To create the VPN connectivity, the CSP or the customer may use the L3VPN service model that SP B exposes. We could consider that, as the NNI is shared, the physical connection (bearer) between CSP A and SP B already exists. CSP A may request through a service model the creation of a new site with a single site-network-access (single-homing is used in the figure). As a placement constraint, CSP A may use the existing bearer reference it has from SP A to force the placement of the VPN NNI on the existing link. The XML below illustrates a possible configuration request to SP B:
要创建VPN连接，CSP或客户可以使用SP B公开的L3VPN服务模型。我们可以认为，当NNI被共享时，CSP A和SP B之间的物理连接（承载）已经存在。CSP A可以通过服务模型请求创建具有单站点网络访问的新站点（图中使用单归宿）。作为放置约束，CSP a可以使用它从SP a获得的现有承载引用来强制在现有链路上放置VPN NNI。下面的XML说明了可能向SP B发出的配置请求：
<site>
<site-id>CSP_A_attachment</site-id>
<location>
<city>NY</city>
<country-code>US</country-code>
</location>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>CSP_A_VN1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>203.0.113.1</provider-address>
<customer-address>203.0.113.2</customer-address>
<mask>30</mask>
</addresses>
</ipv4>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
</service>
<vpn-attachment>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>customer-managed</type>
</management>
</site>
<site>
<site-id>CSP_A_attachment</site-id>
<location>
<city>NY</city>
<country-code>US</country-code>
</location>
<site-vpn-flavor>site-vpn-flavor-nni</site-vpn-flavor>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>CSP_A_VN1</site-network-access-id>
<ip-connection>
<ipv4>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>203.0.113.1</provider-address>
<customer-address>203.0.113.2</customer-address>
<mask>30</mask>
</addresses>
</ipv4>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
</service>
<vpn-attachment>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>customer-managed</type>
</management>
</site>
The case described above is different from a scenario using the cloud-accesses container, as the cloud-access provides a public cloud access while this example enables access to private resources located in a CSP network.
上面描述的情况与使用云访问容器的场景不同，因为云访问提供公共云访问，而此示例允许访问位于CSP网络中的私有资源。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR +<---MP-BGP---->+ ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
In option B, the two ASes are connected to each other with physical links on ASBRs. For resiliency purposes, there may be multiple physical connections between the ASes. The VPN "connection" between ASes is done by exchanging VPN routes through MP-BGP [RFC4760].
在选项B中，两个ASE通过ASBR上的物理链路相互连接。出于弹性目的，ASE之间可能存在多个物理连接。ASE之间的VPN“连接”通过MP-BGP[RFC4760]交换VPN路由来完成。
There are multiple flavors of implementations of such an NNI. For example:
这种NNI有多种实现方式。例如：
1. The NNI is internal to the provider and is situated between a backbone and a data center. There is enough trust between the domains to not filter the VPN routes. So, all the VPN routes are exchanged. RT filtering may be implemented to save some unnecessary route states.
1. NNI位于提供商内部，位于主干网和数据中心之间。域之间有足够的信任，不会过滤VPN路由。因此，所有VPN路由都是交换的。可实施RT过滤以保存一些不必要的路由状态。
2. The NNI is used between providers that agreed to exchange VPN routes for specific RTs only. Each provider is authorized to use the RT values from the other provider.
2. NNI用于同意仅为特定RTs交换VPN路由的提供商之间。每个提供程序都有权使用其他提供程序的RT值。
3. The NNI is used between providers that agreed to exchange VPN routes for specific RTs only. Each provider has its own RT scheme. So, a customer spanning the two networks will have different RTs in each network for a particular VPN.
3. NNI用于同意仅为特定RTs交换VPN路由的提供商之间。每个提供者都有自己的RT方案。因此，跨越两个网络的客户将在每个网络中为特定VPN设置不同的RTs。
Case 1 does not require any service modeling, as the protocol enables the dynamic exchange of necessary VPN routes.
案例1不需要任何服务建模，因为协议允许动态交换必要的VPN路由。
Case 2 requires that an RT-filtering policy on ASBRs be maintained. From a service modeling point of view, it is necessary to agree on the list of RTs to authorize.
案例2要求维护ASBR上的RT筛选策略。从服务建模的角度来看，有必要商定要授权的RTs列表。
In Case 3, both ASes need to agree on the VPN RT to exchange, as well as how to map a VPN RT from AS A to the corresponding RT in AS B (and vice versa).
在案例3中，两个ASE都需要就要交换的VPN RT以及如何将VPN RT从as a映射到as B中的相应RT（反之亦然）达成一致。
Those modelings are currently out of scope for this document.
这些建模目前不在本文档的范围内。
CSP A L3VPN SP B
CSP A L3VPN SP B
----------------- ------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +__________+ + | Site#1
| |-------+ + + + |
| | + ASBR +<-MP-BGP->+ ASBR + |
| | + +__________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / | |
----------------- | |
\ /
------------------
|
|
VPN1
Site#4
----------------- ------------------
/ \ / \
| | | | |
| VM --| ++++++++ NNI ++++++++ |--- VPN1
| | + +__________+ + | Site#1
| |-------+ + + + |
| | + ASBR +<-MP-BGP->+ ASBR + |
| | + +__________+ + |
| | ++++++++ ++++++++ |
| VM --| | | |--- VPN1
| |Virtual | | | Site#2
| |Network | | |
| VM --| | | |--- VPN1
| | | | | Site#3
\ / | |
----------------- | |
\ /
------------------
|
|
VPN1
Site#4
The example above describes an NNI connection between CSP A and SP network B. Both SPs do not trust themselves and use a different RT allocation policy. So, in terms of implementation, the customer VPN has a different RT in each network (RT A in CSP A and RT B in SP network B). In order to connect the customer virtual network in CSP A to the customer IP VPN (VPN1) in SP network B, CSP A should request that SP network B open the customer VPN on the NNI (accept the appropriate RT). Who does the RT translation depends on the agreement between the two SPs: SP B may permit CSP A to request VPN (RT) translation.
上面的示例描述了CSP A和SP网络B之间的NNI连接。两个SP都不信任自己，并使用不同的RT分配策略。因此，就实现而言，客户VPN在每个网络中具有不同的RT（CSP a中的RT a和SP网络B中的RT B）。为了将CSP A中的客户虚拟网络连接到SP网络B中的客户IP VPN（VPN1），CSP A应请求SP网络B在NNI上打开客户VPN（接受适当的RT）。谁进行RT翻译取决于两个SP之间的协议：SP B可能允许CSP A请求VPN（RT）翻译。
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop E-BGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
AS A AS B
------------------- -------------------
/ \ / \
| | | |
| | | |
| | | |
| ++++++++ Multihop E-BGP ++++++++ |
| + + + + |
| + + + + |
| + RGW +<----MP-BGP---->+ RGW + |
| + + + + |
| + + + + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
| | | |
| ++++++++ Inter-AS link ++++++++ |
| + +_______________+ + |
| + + + + |
| + ASBR + + ASBR + |
| + + + + |
| + +_______________+ + |
| ++++++++ ++++++++ |
| | | |
| | | |
\ / \ /
------------------- -------------------
From a VPN service's perspective, the option C NNI is very similar to option B, as an MP-BGP session is used to exchange VPN routes between the ASes. The difference is that the forwarding plane and the control plane are on different nodes, so the MP-BGP session is multihop between routing gateway (RGW) nodes.
从VPN服务的角度来看，选项C NNI与选项B非常相似，因为MP-BGP会话用于在ASE之间交换VPN路由。区别在于转发平面和控制平面位于不同的节点上，因此MP-BGP会话是路由网关（RGW）节点之间的多跳会话。
From a VPN service's point of view, modeling options B and C will be identical.
从VPN服务的角度来看，建模选项B和C是相同的。
As explained in Section 5, this service model is intended to be instantiated at a management layer and is not intended to be used directly on network elements. The management system serves as a central point of configuration of the overall service.
如第5节所述，此服务模型旨在在管理层实例化，而不是直接用于网络元素。管理系统是整个服务配置的中心点。
This section provides an example of how a management system can use this model to configure an IP VPN service on network elements.
本节提供了管理系统如何使用此模型在网元上配置IP VPN服务的示例。
In this example, we want to achieve the provisioning of a VPN service for three sites using a Hub-and-Spoke VPN service topology. One of the sites will be dual-homed, and load-sharing is expected.
在本例中，我们希望使用中心辐射式VPN服务拓扑为三个站点提供VPN服务。其中一个站点将是双主站点，并且预期负载共享。
+-------------------------------------------------------------+
| Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
| | +----------------------------------+
| | |
| | +----------------------------------+
| Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| Hub_Site ------ PE1 PE2 ------ Spoke_Site1 |
| | +----------------------------------+
| | |
| | +----------------------------------+
| Hub_Site ------ PE3 PE4 ------ Spoke_Site2 |
+-------------------------------------------------------------+
The following XML describes the overall simplified service configuration of this VPN.
以下XML描述了此VPN的整体简化服务配置。
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
<vpn-service>
<vpn-id>12456487</vpn-id>
<vpn-service-topology>hub-spoke</vpn-service-topology>
</vpn-service>
When receiving the request for provisioning the VPN service, the management system will internally (or through communication with another OSS component) allocate VPN RTs. In this specific case, two RTs will be allocated (100:1 for Hub and 100:2 for Spoke). The output below describes the configuration of Spoke_Site1.
当收到提供VPN服务的请求时，管理系统将在内部（或通过与另一个OSS组件通信）分配VPN RTs。在这种特定情况下，将分配两个RTs（集线器为100:1，轮辐为100:2）。下面的输出描述了Spoke_Site1的配置。
<site>
<site-id>Spoke_Site1</site-id>
<location>
<city>NY</city>
<country-code>US</country-code>
</location>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>Spoke_Site1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<ip-connection>
<ipv4>
<address-allocation-type>
static-address
</address-allocation-type>
<site>
<site-id>Spoke_Site1</site-id>
<location>
<city>NY</city>
<country-code>US</country-code>
</location>
<routing-protocols>
<routing-protocol>
<type>bgp</type>
<bgp>
<autonomous-system>500</autonomous-system>
<address-family>ipv4</address-family>
<address-family>ipv6</address-family>
</bgp>
</routing-protocol>
</routing-protocols>
<site-network-accesses>
<site-network-access>
<site-network-access-id>Spoke_Site1</site-network-access-id>
<access-diversity>
<groups>
<group>
<group-id>20</group-id>
</group>
</groups>
<constraints>
<constraint>
<constraint-type>pe-diverse</constraint-type>
<target>
<group>
<group-id>10</group-id>
</group>
</target>
</constraint>
</constraints>
</access-diversity>
<ip-connection>
<ipv4>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>203.0.113.254</provider-address>
<customer-address>203.0.113.2</customer-address>
<mask>24</mask>
</addresses>
</ipv4>
<ipv6>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>2001:db8::1</provider-address>
<customer-address>2001:db8::2</customer-address>
<mask>64</mask>
</addresses>
</ipv6>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
</service>
<vpn-attachment>
<vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>provider-managed</type>
</management>
</site>
<addresses>
<provider-address>203.0.113.254</provider-address>
<customer-address>203.0.113.2</customer-address>
<mask>24</mask>
</addresses>
</ipv4>
<ipv6>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>2001:db8::1</provider-address>
<customer-address>2001:db8::2</customer-address>
<mask>64</mask>
</addresses>
</ipv6>
</ip-connection>
<service>
<svc-input-bandwidth>450000000</svc-input-bandwidth>
<svc-output-bandwidth>450000000</svc-output-bandwidth>
</service>
<vpn-attachment>
<vpn-id>12456487</vpn-id>
<site-role>spoke-role</site-role>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<management>
<type>provider-managed</type>
</management>
</site>
When receiving the request for provisioning Spoke_Site1, the management system MUST allocate network resources for this site. It MUST first determine the target network elements to provision the access, particularly the PE router (and perhaps also an aggregation switch). As described in Section 6.6, the management system SHOULD use the location information and SHOULD use the access-diversity constraint to find the appropriate PE. In this case, we consider that Spoke_Site1 requires PE diversity with the Hub and that the management system allocates PEs based on the least distance. Based on the location information, the management system finds the available PEs in the area nearest the customer and picks one that fits the access-diversity constraint.
当接收到设置站点1的请求时，管理系统必须为此站点分配网络资源。它必须首先确定提供访问的目标网络元素，特别是PE路由器（可能还有聚合交换机）。如第6.6节所述，管理系统应使用位置信息，并应使用接入分集约束来找到适当的PE。在这种情况下，我们认为SpoKySITE1需要与集线器的PE多样性，并且管理系统基于最小距离分配PES。根据位置信息，管理系统在离客户最近的区域找到可用的PE，并选择一个符合访问多样性约束的PE。
When the PE is chosen, the management system needs to allocate interface resources on the node. One interface is selected from the pool of available PEs. The management system can start provisioning the chosen PE node via whatever means the management system prefers (e.g., NETCONF, CLI). The management system will check to see if a VRF that fits its needs is already present. If not, it will provision the VRF: the RD will be derived from the internal allocation policy model, and the RTs will be derived from the VPN policy configuration of the site (the management system allocated some RTs for the VPN). As the site is a Spoke site (site-role), the management system knows which RTs must be imported and exported. As the site is provider-managed, some management RTs may also be added (100:5000). Standard provider VPN policies MAY also be added in the configuration.
当选择PE时，管理系统需要在节点上分配接口资源。从可用PE池中选择一个接口。管理系统可以通过管理系统喜欢的任何方式（如NETCONF、CLI）开始配置所选PE节点。管理系统将检查是否已经存在符合其需求的VRF。如果没有，它将提供VRF：RD将从内部分配策略模型派生，RTs将从站点的VPN策略配置派生（管理系统为VPN分配了一些RTs）。由于站点是辐射站点（站点角色），管理系统知道必须导入和导出哪些RTs。由于站点由提供商管理，因此还可以添加一些管理RTs（100:5000）。配置中还可以添加标准提供商VPN策略。
Example of generated PE configuration:
生成的PE配置示例：
ip vrf Customer1
export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
route-distinguisher 100:3123234324
route-target import 100:1
route-target import 100:5000 <---- Standard SP configuration
route-target export 100:2 for provider-managed CE
!
ip vrf Customer1
export-map STD-CUSTOMER-EXPORT <---- Standard SP configuration
route-distinguisher 100:3123234324
route-target import 100:1
route-target import 100:5000 <---- Standard SP configuration
route-target export 100:2 for provider-managed CE
!
When the VRF has been provisioned, the management system can start configuring the access on the PE using the allocated interface information. IP addressing is chosen by the management system. One address will be picked from an allocated subnet for the PE, and another will be used for the CE configuration. Routing protocols will also be configured between the PE and CE; because this model is provider-managed, the choices are left to the SP. BGP was chosen for this example. This choice is independent of the routing protocol chosen by the customer. BGP will be used to configure the CE-to-LAN connection as requested in the service model. Peering addresses will be derived from those of the connection. As the CE is provider-managed, the CE's AS number can be automatically allocated by the management system. Standard configuration templates provided by the SP may also be added.
配置VRF后，管理系统可以开始使用分配的接口信息在PE上配置访问。IP地址由管理系统选择。一个地址将从分配给PE的子网中选取，另一个地址将用于CE配置。PE和CE之间还将配置路由协议；由于此模型由提供程序管理，因此选择权留给SP。本例中选择了BGP。此选择与客户选择的路由协议无关。BGP将用于根据服务模型中的请求配置CE到LAN的连接。对等地址将从连接的对等地址派生。由于CE由提供商管理，因此管理系统可以自动分配CE的As编号。还可以添加SP提供的标准配置模板。
Example of generated PE configuration:
生成的PE配置示例：
interface Ethernet1/1/0.10
encapsulation dot1q 10
ip vrf forwarding Customer1
ip address 198.51.100.1 255.255.255.252 <---- Comes from
automated allocation
ipv6 address 2001:db8::10:1/64
ip access-group STD-PROTECT-IN <---- Standard SP config
!
router bgp 100
address-family ipv4 vrf Customer1
neighbor 198.51.100.2 remote-as 65000 <---- Comes from
automated allocation
neighbor 198.51.100.2 route-map STD in <---- Standard SP config
neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
!
address-family ipv6 vrf Customer1
neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from
automated allocation
neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP
config
neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP
config
!
ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
! Static route for provider administration of CE
!
interface Ethernet1/1/0.10
encapsulation dot1q 10
ip vrf forwarding Customer1
ip address 198.51.100.1 255.255.255.252 <---- Comes from
automated allocation
ipv6 address 2001:db8::10:1/64
ip access-group STD-PROTECT-IN <---- Standard SP config
!
router bgp 100
address-family ipv4 vrf Customer1
neighbor 198.51.100.2 remote-as 65000 <---- Comes from
automated allocation
neighbor 198.51.100.2 route-map STD in <---- Standard SP config
neighbor 198.51.100.2 filter-list 10 in <---- Standard SP config
!
address-family ipv6 vrf Customer1
neighbor 2001:db8::0a10:2 remote-as 65000 <---- Comes from
automated allocation
neighbor 2001:db8::0a10:2 route-map STD in <---- Standard SP
config
neighbor 2001:db8::0a10:2 filter-list 10 in <---- Standard SP
config
!
ip route vrf Customer1 192.0.2.1 255.255.255.255 198.51.100.2
! Static route for provider administration of CE
!
As the CE router is not reachable at this stage, the management system can produce a complete CE configuration that can be manually uploaded to the node before sending the CE configuration to the customer premises. The CE configuration will be built in the same way as the PE would be configured. Based on the CE type (vendor/model) allocated to the customer as well as the bearer information, the management system knows which interface must be configured on the CE. PE-CE link configuration is expected to be handled automatically using the SP OSS, as both resources are managed internally. CE-to-LAN-interface parameters such as IP addressing are derived from the ip-connection container, taking into account how the management system distributes addresses between the PE and CE within the subnet. This will allow a plug-and-play configuration for the CE to be created.
由于在此阶段无法访问CE路由器，管理系统可以生成完整的CE配置，可以在将CE配置发送到客户场所之前手动上载到节点。CE配置将以与PE配置相同的方式构建。根据分配给客户的CE类型（供应商/型号）以及承载信息，管理系统知道必须在CE上配置哪个接口。PE-CE链路配置预计将使用SP OSS自动处理，因为这两种资源都是内部管理的。CE到LAN接口参数（如IP地址）源自IP连接容器，考虑到管理系统如何在子网内的PE和CE之间分配地址。这将允许创建CE的即插即用配置。
Example of generated CE configuration:
生成的CE配置示例：
interface Loopback10
description "Administration"
ip address 192.0.2.1 255.255.255.255
!
interface FastEthernet10
description "WAN"
ip address 198.51.100.2 255.255.255.252 <---- Comes from
automated allocation
ipv6 address 2001:db8::0a10:2/64
!
interface FastEthernet11
description "LAN"
ip address 203.0.113.254 255.255.255.0 <---- Comes from the
ip-connection container
ipv6 address 2001:db8::1/64
!
router bgp 65000
address-family ipv4
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 198.51.100.1 remote-as 100 <---- Comes from
automated allocation
neighbor 203.0.113.2 remote-as 500 <---- Comes from the
ip-connection container
address-family ipv6
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from
automated allocation
neighbor 2001:db8::2 remote-as 500 <---- Comes from the
ip-connection container
!
route-map STATIC2BGP permit 10
match tag 10
!
interface Loopback10
description "Administration"
ip address 192.0.2.1 255.255.255.255
!
interface FastEthernet10
description "WAN"
ip address 198.51.100.2 255.255.255.252 <---- Comes from
automated allocation
ipv6 address 2001:db8::0a10:2/64
!
interface FastEthernet11
description "LAN"
ip address 203.0.113.254 255.255.255.0 <---- Comes from the
ip-connection container
ipv6 address 2001:db8::1/64
!
router bgp 65000
address-family ipv4
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 198.51.100.1 remote-as 100 <---- Comes from
automated allocation
neighbor 203.0.113.2 remote-as 500 <---- Comes from the
ip-connection container
address-family ipv6
redistribute static route-map STATIC2BGP <---- Standard SP
configuration
neighbor 2001:db8::0a10:1 remote-as 100 <---- Comes from
automated allocation
neighbor 2001:db8::2 remote-as 500 <---- Comes from the
ip-connection container
!
route-map STATIC2BGP permit 10
match tag 10
!
As expressed in Section 5, this service model is intended to be instantiated in a management system and not directly on network elements.
如第5节所述，此服务模型旨在在管理系统中实例化，而不是直接在网络元素上实例化。
The management system's role will be to configure the network elements. The management system may be modular, so the component instantiating the service model (let's call it "service component") and the component responsible for network element configuration (let's call it "configuration component") may be different.
管理系统的作用是配置网络元件。管理系统可能是模块化的，因此实例化服务模型的组件（我们称之为“服务组件”）和负责网元配置的组件（我们称之为“配置组件”）可能不同。
l3vpn-svc |
Model |
|
+---------------------+
| Service component | Service datastore
+---------------------+
|
|
+---------------------+
+----| Config component |------+
/ +---------------------+ \ Network
/ / \ \ Configuration
/ / \ \ models
/ / \ \
++++++++ ++++++++ ++++++++ ++++++++
+ CE A + ------- + PE A + + PE B + ----- + CE B + Config
++++++++ ++++++++ ++++++++ ++++++++ datastore
l3vpn-svc |
Model |
|
+---------------------+
| Service component | Service datastore
+---------------------+
|
|
+---------------------+
+----| Config component |------+
/ +---------------------+ \ Network
/ / \ \ Configuration
/ / \ \ models
/ / \ \
++++++++ ++++++++ ++++++++ ++++++++
+ CE A + ------- + PE A + + PE B + ----- + CE B + Config
++++++++ ++++++++ ++++++++ ++++++++ datastore
Site A Site B
场地A场地B
In the previous sections, we provided some examples of the translation of service provisioning requests to router configuration lines. In the NETCONF/YANG ecosystem, we expect NETCONF/YANG to be used between the configuration component and network elements to configure the requested services on those elements.
在前面的部分中，我们提供了一些将服务提供请求转换为路由器配置行的示例。在NETCONF/YANG生态系统中，我们希望在配置组件和网络元素之间使用NETCONF/YANG来配置这些元素上请求的服务。
In this framework, specifications are expected to provide specific YANG modeling of service components on network elements. There will be a strong relationship between the abstracted view provided by this service model and the detailed configuration view that will be provided by specific configuration models for network elements.
在此框架中，规范将提供网络元素上服务组件的特定建模。此服务模型提供的抽象视图与网络元素的特定配置模型提供的详细配置视图之间存在着密切的关系。
The authors of this document anticipate definitions of YANG models for the network elements listed below. Note that this list is not exhaustive:
本文件的作者预期以下列出的网络元素的YANG模型的定义。请注意，此列表并非详尽无遗：
o VRF definition, including VPN policy expression.
o VRF定义，包括VPN策略表达式。
o Physical interface.
o 物理接口。
o IP layer (IPv4, IPv6).
o IP层（IPv4、IPv6）。
o QoS: classification, profiles, etc.
o QoS：分类、配置文件等。
o Routing protocols: support of configuration of all protocols listed in the document, as well as routing policies associated with those protocols.
o 路由协议：支持文档中列出的所有协议的配置，以及与这些协议相关联的路由策略。
o Multicast VPN.
o 多播VPN。
o Network address translation.
o 网络地址转换。
Example of a VPN site request at the service level, using this model:
使用此模型的服务级别上的VPN站点请求示例：
<site>
<site-id>Site A</site-id>
<site-network-accesses>
<site-network-access>
<ip-connection>
<ipv4>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>203.0.113.254</provider-address>
<customer-address>203.0.113.2</customer-address>
<mask>24</mask>
</addresses>
</ipv4>
</ip-connection>
<vpn-attachment>
<vpn-policy-id>VPNPOL1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<site>
<site-id>Site A</site-id>
<site-network-accesses>
<site-network-access>
<ip-connection>
<ipv4>
<address-allocation-type>
static-address
</address-allocation-type>
<addresses>
<provider-address>203.0.113.254</provider-address>
<customer-address>203.0.113.2</customer-address>
<mask>24</mask>
</addresses>
</ipv4>
</ip-connection>
<vpn-attachment>
<vpn-policy-id>VPNPOL1</vpn-policy-id>
</vpn-attachment>
</site-network-access>
</site-network-accesses>
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>198.51.100.0/30</lan>
<next-hop>203.0.113.2</next-hop>
</ipv4-lan-prefixes>
</cascaded-lan-prefixes>
</static>
</routing-protocol>
</routing-protocols>
<management>
<type>customer-managed</type>
</management>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>VPNPOL1</vpn-policy-id>
<entries>
<id>1</id>
<vpn>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
</site>
<routing-protocols>
<routing-protocol>
<type>static</type>
<static>
<cascaded-lan-prefixes>
<ipv4-lan-prefixes>
<lan>198.51.100.0/30</lan>
<next-hop>203.0.113.2</next-hop>
</ipv4-lan-prefixes>
</cascaded-lan-prefixes>
</static>
</routing-protocol>
</routing-protocols>
<management>
<type>customer-managed</type>
</management>
<vpn-policies>
<vpn-policy>
<vpn-policy-id>VPNPOL1</vpn-policy-id>
<entries>
<id>1</id>
<vpn>
<vpn-id>VPN1</vpn-id>
<site-role>any-to-any-role</site-role>
</vpn>
</entries>
</vpn-policy>
</vpn-policies>
</site>
In the service example above, the service component is expected to request that the configuration component of the management system provide the configuration of the service elements. If we consider that the service component selected a PE (PE A) as the target PE for the site, the configuration component will need to push the configuration to PE A. The configuration component will use several YANG data models to define the configuration to be applied to PE A. The XML configuration of PE A might look like this:
在上面的服务示例中，服务组件将请求管理系统的配置组件提供服务元素的配置。如果我们认为服务组件选择PE（PE A）作为站点的目标PE，那么配置组件将需要将配置推送到PE A。配置组件将使用多个杨树数据模型来定义要应用于PE A的配置。PE A的XML配置可能看起来是这样的：
<if:interfaces>
<if:interface>
<if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type>
<if:description>
Link to CE A.
</if:description>
<ip:ipv4>
<ip:address>
<if:interfaces>
<if:interface>
<if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type>
<if:description>
Link to CE A.
</if:description>
<ip:ipv4>
<ip:address>
<ip:ip>203.0.113.254</ip:ip>
<ip:prefix-length>24</ip:prefix-length>
</ip:address>
<ip:forwarding>true</ip:forwarding>
</ip:ipv4>
</if:interface>
</if:interfaces>
<rt:routing>
<rt:routing-instance>
<rt:name>VRF_CustA</rt:name>
<rt:type>l3vpn-network:vrf</rt:type>
<rt:description>VRF for Customer A</rt:description>
<l3vpn-network:route-distinguisher>
100:1546542343
</l3vpn-network:route-distinguisher>
<l3vpn-network:import-rt>100:1</l3vpn-network:import-rt>
<l3vpn-network:export-rt>100:1</l3vpn-network:export-rt>
<rt:interfaces>
<rt:interface>
<rt:name>eth0</rt:name>
</rt:interface>
</rt:interfaces>
<rt:routing-protocols>
<rt:routing-protocol>
<rt:type>rt:static</rt:type>
<rt:name>st0</rt:name>
<rt:static-routes>
<v4ur:ipv4>
<v4ur:route>
<v4ur:destination-prefix>
198.51.100.0/30
</v4ur:destination-prefix>
<v4ur:next-hop>
<v4ur:next-hop-address>
203.0.113.2
</v4ur:next-hop-address>
</v4ur:next-hop>
</v4ur:route>
</v4ur:ipv4>
</rt:static-routes>
</rt:routing-protocol>
</rt:routing-protocols>
</rt:routing-instance>
</rt:routing>
<ip:ip>203.0.113.254</ip:ip>
<ip:prefix-length>24</ip:prefix-length>
</ip:address>
<ip:forwarding>true</ip:forwarding>
</ip:ipv4>
</if:interface>
</if:interfaces>
<rt:routing>
<rt:routing-instance>
<rt:name>VRF_CustA</rt:name>
<rt:type>l3vpn-network:vrf</rt:type>
<rt:description>VRF for Customer A</rt:description>
<l3vpn-network:route-distinguisher>
100:1546542343
</l3vpn-network:route-distinguisher>
<l3vpn-network:import-rt>100:1</l3vpn-network:import-rt>
<l3vpn-network:export-rt>100:1</l3vpn-network:export-rt>
<rt:interfaces>
<rt:interface>
<rt:name>eth0</rt:name>
</rt:interface>
</rt:interfaces>
<rt:routing-protocols>
<rt:routing-protocol>
<rt:type>rt:static</rt:type>
<rt:name>st0</rt:name>
<rt:static-routes>
<v4ur:ipv4>
<v4ur:route>
<v4ur:destination-prefix>
198.51.100.0/30
</v4ur:destination-prefix>
<v4ur:next-hop>
<v4ur:next-hop-address>
203.0.113.2
</v4ur:next-hop-address>
</v4ur:next-hop>
</v4ur:route>
</v4ur:ipv4>
</rt:static-routes>
</rt:routing-protocol>
</rt:routing-protocols>
</rt:routing-instance>
</rt:routing>
<CODE BEGINS>
<代码开始>
file "ietf-l3vpn-svc@2017-01-27.yang"
文件“ietf-l3vpn-svc@2017-01-27.杨”
module ietf-l3vpn-svc {
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
module ietf-l3vpn-svc {
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
prefix l3vpn-svc;
前缀l3vpn svc；
import ietf-inet-types {
prefix inet;
}
import ietf-inet-types {
prefix inet;
}
import ietf-yang-types {
prefix yang;
}
import ietf-yang-types {
prefix yang;
}
organization "IETF L3SM Working Group";
组织“IETF L3SM工作组”；
contact
"WG List: <mailto:l3sm@ietf.org>
contact
"WG List: <mailto:l3sm@ietf.org>
Editor: L3SM WG
编辑：L3SM工作组
Chairs: Adrian Farrel, Qin Wu ";
主席：阿德里安·法雷尔，秦武”；
description "This YANG module defines a generic service configuration model for Layer 3 VPNs. This model is common across all vendor implementations.";
description“此模块为第3层VPN定义了一个通用服务配置模型。此模型在所有供应商实施中都是通用的。”；
revision 2017-01-27 {
description
"Initial document.";
reference
"RFC 8049.";
}
revision 2017-01-27 {
description
"Initial document.";
reference
"RFC 8049.";
}
/* Features */
/* Features */
feature cloud-access {
description
"Allows the VPN to connect to a CSP.";
}
feature multicast {
description
"Enables multicast capabilities in a VPN.";
}
feature ipv4 {
description
"Enables IPv4 support in a VPN.";
}
feature ipv6 {
description
"Enables IPv6 support in a VPN.";
}
feature carrierscarrier {
description
"Enables support of CsC.";
}
feature extranet-vpn {
description
"Enables support of extranet VPNs.";
}
feature site-diversity {
description
"Enables support of site diversity constraints.";
}
feature encryption {
description
"Enables support of encryption.";
}
feature qos {
description
"Enables support of classes of services.";
}
feature qos-custom {
description
"Enables support of the custom QoS profile.";
}
feature rtg-bgp {
description
"Enables support of the BGP routing protocol.";
}
feature cloud-access {
description
"Allows the VPN to connect to a CSP.";
}
feature multicast {
description
"Enables multicast capabilities in a VPN.";
}
feature ipv4 {
description
"Enables IPv4 support in a VPN.";
}
feature ipv6 {
description
"Enables IPv6 support in a VPN.";
}
feature carrierscarrier {
description
"Enables support of CsC.";
}
feature extranet-vpn {
description
"Enables support of extranet VPNs.";
}
feature site-diversity {
description
"Enables support of site diversity constraints.";
}
feature encryption {
description
"Enables support of encryption.";
}
feature qos {
description
"Enables support of classes of services.";
}
feature qos-custom {
description
"Enables support of the custom QoS profile.";
}
feature rtg-bgp {
description
"Enables support of the BGP routing protocol.";
}
feature rtg-rip {
description
"Enables support of the RIP routing protocol.";
}
feature rtg-ospf {
description
"Enables support of the OSPF routing protocol.";
}
feature rtg-ospf-sham-link {
description
"Enables support of OSPF sham links.";
}
feature rtg-vrrp {
description
"Enables support of the VRRP routing protocol.";
}
feature fast-reroute {
description
"Enables support of Fast Reroute.";
}
feature bfd {
description
"Enables support of BFD.";
}
feature always-on {
description
"Enables support of the 'always-on' access constraint.";
}
feature requested-type {
description
"Enables support of the 'requested-type' access constraint.";
}
feature bearer-reference {
description
"Enables support of the 'bearer-reference' access constraint.";
}
feature rtg-rip {
description
"Enables support of the RIP routing protocol.";
}
feature rtg-ospf {
description
"Enables support of the OSPF routing protocol.";
}
feature rtg-ospf-sham-link {
description
"Enables support of OSPF sham links.";
}
feature rtg-vrrp {
description
"Enables support of the VRRP routing protocol.";
}
feature fast-reroute {
description
"Enables support of Fast Reroute.";
}
feature bfd {
description
"Enables support of BFD.";
}
feature always-on {
description
"Enables support of the 'always-on' access constraint.";
}
feature requested-type {
description
"Enables support of the 'requested-type' access constraint.";
}
feature bearer-reference {
description
"Enables support of the 'bearer-reference' access constraint.";
}
/* Typedefs */
/* Typedefs */
typedef svc-id {
type string;
description
"Defines a type of service component identifier.";
}
typedef svc-id {
type string;
description
"Defines a type of service component identifier.";
}
typedef template-id {
type string;
description
"Defines a type of service template identifier.";
}
typedef template-id {
type string;
description
"Defines a type of service template identifier.";
}
typedef address-family {
type enumeration {
enum ipv4 {
description
"IPv4 address family.";
}
enum ipv6 {
description
"IPv6 address family.";
}
}
description
"Defines a type for the address family.";
}
typedef address-family {
type enumeration {
enum ipv4 {
description
"IPv4 address family.";
}
enum ipv6 {
description
"IPv6 address family.";
}
}
description
"Defines a type for the address family.";
}
/* Identities */
/* Identities */
identity site-network-access-type {
description
"Base identity for site-network-access type.";
}
identity point-to-point {
base site-network-access-type;
description
"Identity for point-to-point connection.";
}
identity multipoint {
base site-network-access-type;
description
"Identity for multipoint connection.
Example: Ethernet broadcast segment.";
}
identity placement-diversity {
description
"Base identity for site placement constraints.";
}
identity bearer-diverse {
base placement-diversity;
description
"Identity for bearer diversity.
The bearers should not use common elements.";
}
identity site-network-access-type {
description
"Base identity for site-network-access type.";
}
identity point-to-point {
base site-network-access-type;
description
"Identity for point-to-point connection.";
}
identity multipoint {
base site-network-access-type;
description
"Identity for multipoint connection.
Example: Ethernet broadcast segment.";
}
identity placement-diversity {
description
"Base identity for site placement constraints.";
}
identity bearer-diverse {
base placement-diversity;
description
"Identity for bearer diversity.
The bearers should not use common elements.";
}
identity pe-diverse {
base placement-diversity;
description
"Identity for PE diversity.";
}
identity pop-diverse {
base placement-diversity;
description
"Identity for POP diversity.";
}
identity linecard-diverse {
base placement-diversity;
description
"Identity for linecard diversity.";
}
identity same-pe {
base placement-diversity;
description
"Identity for having sites connected on the same PE.";
}
identity same-bearer {
base placement-diversity;
description
"Identity for having sites connected using the same bearer.";
}
identity customer-application {
description
"Base identity for customer application.";
}
identity web {
base customer-application;
description
"Identity for Web application (e.g., HTTP, HTTPS).";
}
identity mail {
base customer-application;
description
"Identity for mail application.";
}
identity file-transfer {
base customer-application;
description
"Identity for file transfer application (e.g., FTP, SFTP).";
}
identity pe-diverse {
base placement-diversity;
description
"Identity for PE diversity.";
}
identity pop-diverse {
base placement-diversity;
description
"Identity for POP diversity.";
}
identity linecard-diverse {
base placement-diversity;
description
"Identity for linecard diversity.";
}
identity same-pe {
base placement-diversity;
description
"Identity for having sites connected on the same PE.";
}
identity same-bearer {
base placement-diversity;
description
"Identity for having sites connected using the same bearer.";
}
identity customer-application {
description
"Base identity for customer application.";
}
identity web {
base customer-application;
description
"Identity for Web application (e.g., HTTP, HTTPS).";
}
identity mail {
base customer-application;
description
"Identity for mail application.";
}
identity file-transfer {
base customer-application;
description
"Identity for file transfer application (e.g., FTP, SFTP).";
}
identity database {
base customer-application;
description
"Identity for database application.";
}
identity social {
base customer-application;
description
"Identity for social-network application.";
}
identity games {
base customer-application;
description
"Identity for gaming application.";
}
identity p2p {
base customer-application;
description
"Identity for peer-to-peer application.";
}
identity network-management {
base customer-application;
description
"Identity for management application
(e.g., Telnet, syslog, SNMP).";
}
identity voice {
base customer-application;
description
"Identity for voice application.";
}
identity video {
base customer-application;
description
"Identity for video conference application.";
}
identity site-vpn-flavor {
description
"Base identity for the site VPN service flavor.";
}
identity site-vpn-flavor-single {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when the site belongs to only one VPN.";
}
identity database {
base customer-application;
description
"Identity for database application.";
}
identity social {
base customer-application;
description
"Identity for social-network application.";
}
identity games {
base customer-application;
description
"Identity for gaming application.";
}
identity p2p {
base customer-application;
description
"Identity for peer-to-peer application.";
}
identity network-management {
base customer-application;
description
"Identity for management application
(e.g., Telnet, syslog, SNMP).";
}
identity voice {
base customer-application;
description
"Identity for voice application.";
}
identity video {
base customer-application;
description
"Identity for video conference application.";
}
identity site-vpn-flavor {
description
"Base identity for the site VPN service flavor.";
}
identity site-vpn-flavor-single {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when the site belongs to only one VPN.";
}
identity site-vpn-flavor-multi {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when a logical connection of a site
belongs to multiple VPNs.";
}
identity site-vpn-flavor-sub {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when a site has multiple logical connections.
Each connection may belong to different multiple VPNs.";
}
identity site-vpn-flavor-nni {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used to describe an NNI option A connection.";
}
identity management {
description
"Base identity for site management scheme.";
}
identity co-managed {
base management;
description
"Base identity for co-managed site.";
}
identity customer-managed {
base management;
description
"Base identity for customer-managed site.";
}
identity provider-managed {
base management;
description
"Base identity for provider-managed site.";
}
identity address-allocation-type {
description
"Base identity for address-allocation-type for PE-CE link.";
}
identity provider-dhcp {
base address-allocation-type;
description
"Provider network provides DHCP service to customer.";
}
identity site-vpn-flavor-multi {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when a logical connection of a site
belongs to multiple VPNs.";
}
identity site-vpn-flavor-sub {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used when a site has multiple logical connections.
Each connection may belong to different multiple VPNs.";
}
identity site-vpn-flavor-nni {
base site-vpn-flavor;
description
"Base identity for the site VPN service flavor.
Used to describe an NNI option A connection.";
}
identity management {
description
"Base identity for site management scheme.";
}
identity co-managed {
base management;
description
"Base identity for co-managed site.";
}
identity customer-managed {
base management;
description
"Base identity for customer-managed site.";
}
identity provider-managed {
base management;
description
"Base identity for provider-managed site.";
}
identity address-allocation-type {
description
"Base identity for address-allocation-type for PE-CE link.";
}
identity provider-dhcp {
base address-allocation-type;
description
"Provider network provides DHCP service to customer.";
}
identity provider-dhcp-relay {
base address-allocation-type;
description
"Provider network provides DHCP relay service to customer.";
}
identity provider-dhcp-slaac {
base address-allocation-type;
description
"Provider network provides DHCP service to customer,
as well as SLAAC.";
}
identity static-address {
base address-allocation-type;
description
"Provider-to-customer addressing is static.";
}
identity slaac {
base address-allocation-type;
description
"Use IPv6 SLAAC.";
}
identity provider-dhcp-relay {
base address-allocation-type;
description
"Provider network provides DHCP relay service to customer.";
}
identity provider-dhcp-slaac {
base address-allocation-type;
description
"Provider network provides DHCP service to customer,
as well as SLAAC.";
}
identity static-address {
base address-allocation-type;
description
"Provider-to-customer addressing is static.";
}
identity slaac {
base address-allocation-type;
description
"Use IPv6 SLAAC.";
}
identity site-role {
description
"Base identity for site type.";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any IP VPN.";
}
identity spoke-role {
base site-role;
description
"Spoke site in a Hub-and-Spoke IP VPN.";
}
identity hub-role {
base site-role;
description
"Hub site in a Hub-and-Spoke IP VPN.";
}
identity site-role {
description
"Base identity for site type.";
}
identity any-to-any-role {
base site-role;
description
"Site in an any-to-any IP VPN.";
}
identity spoke-role {
base site-role;
description
"Spoke site in a Hub-and-Spoke IP VPN.";
}
identity hub-role {
base site-role;
description
"Hub site in a Hub-and-Spoke IP VPN.";
}
identity vpn-topology {
description
"Base identity for VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for any-to-any VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology
where Hubs cannot communicate with each other.";
}
identity vpn-topology {
description
"Base identity for VPN topology.";
}
identity any-to-any {
base vpn-topology;
description
"Identity for any-to-any VPN topology.";
}
identity hub-spoke {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology.";
}
identity hub-spoke-disjoint {
base vpn-topology;
description
"Identity for Hub-and-Spoke VPN topology
where Hubs cannot communicate with each other.";
}
identity multicast-tree-type {
description
"Base identity for multicast tree type.";
}
identity ssm-tree-type {
base multicast-tree-type;
description
"Identity for SSM tree type.";
}
identity asm-tree-type {
base multicast-tree-type;
description
"Identity for ASM tree type.";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for bidirectional tree type.";
}
identity multicast-tree-type {
description
"Base identity for multicast tree type.";
}
identity ssm-tree-type {
base multicast-tree-type;
description
"Identity for SSM tree type.";
}
identity asm-tree-type {
base multicast-tree-type;
description
"Identity for ASM tree type.";
}
identity bidir-tree-type {
base multicast-tree-type;
description
"Identity for bidirectional tree type.";
}
identity multicast-rp-discovery-type {
description
"Base identity for RP discovery type.";
}
identity multicast-rp-discovery-type {
description
"Base identity for RP discovery type.";
}
identity auto-rp {
base multicast-rp-discovery-type;
description
"Base identity for Auto-RP discovery type.";
}
identity static-rp {
base multicast-rp-discovery-type;
description
"Base identity for static type.";
}
identity bsr-rp {
base multicast-rp-discovery-type;
description
"Base identity for BSR discovery type.";
}
identity auto-rp {
base multicast-rp-discovery-type;
description
"Base identity for Auto-RP discovery type.";
}
identity static-rp {
base multicast-rp-discovery-type;
description
"Base identity for static type.";
}
identity bsr-rp {
base multicast-rp-discovery-type;
description
"Base identity for BSR discovery type.";
}
identity routing-protocol-type {
description
"Base identity for routing protocol type.";
}
identity ospf {
base routing-protocol-type;
description
"Identity for OSPF protocol type.";
}
identity bgp {
base routing-protocol-type;
description
"Identity for BGP protocol type.";
}
identity static {
base routing-protocol-type;
description
"Identity for static routing protocol type.";
}
identity rip {
base routing-protocol-type;
description
"Identity for RIP protocol type.";
}
identity vrrp {
base routing-protocol-type;
description
"Identity for VRRP protocol type.
This is to be used when LANs are directly connected
to PE routers.";
}
identity routing-protocol-type {
description
"Base identity for routing protocol type.";
}
identity ospf {
base routing-protocol-type;
description
"Identity for OSPF protocol type.";
}
identity bgp {
base routing-protocol-type;
description
"Identity for BGP protocol type.";
}
identity static {
base routing-protocol-type;
description
"Identity for static routing protocol type.";
}
identity rip {
base routing-protocol-type;
description
"Identity for RIP protocol type.";
}
identity vrrp {
base routing-protocol-type;
description
"Identity for VRRP protocol type.
This is to be used when LANs are directly connected
to PE routers.";
}
identity direct {
base routing-protocol-type;
description
"Identity for direct protocol type.";
}
identity direct {
base routing-protocol-type;
description
"Identity for direct protocol type.";
}
identity protocol-type {
description
"Base identity for protocol field type.";
}
identity tcp {
base protocol-type;
description
"TCP protocol type.";
}
identity udp {
base protocol-type;
description
"UDP protocol type.";
}
identity icmp {
base protocol-type;
description
"ICMP protocol type.";
}
identity icmp6 {
base protocol-type;
description
"ICMPv6 protocol type.";
}
identity gre {
base protocol-type;
description
"GRE protocol type.";
}
identity ipip {
base protocol-type;
description
"IP-in-IP protocol type.";
}
identity hop-by-hop {
base protocol-type;
description
"Hop-by-Hop IPv6 header type.";
}
identity protocol-type {
description
"Base identity for protocol field type.";
}
identity tcp {
base protocol-type;
description
"TCP protocol type.";
}
identity udp {
base protocol-type;
description
"UDP protocol type.";
}
identity icmp {
base protocol-type;
description
"ICMP protocol type.";
}
identity icmp6 {
base protocol-type;
description
"ICMPv6 protocol type.";
}
identity gre {
base protocol-type;
description
"GRE protocol type.";
}
identity ipip {
base protocol-type;
description
"IP-in-IP protocol type.";
}
identity hop-by-hop {
base protocol-type;
description
"Hop-by-Hop IPv6 header type.";
}
identity routing {
base protocol-type;
description
"Routing IPv6 header type.";
}
identity esp {
base protocol-type;
description
"ESP header type.";
}
identity ah {
base protocol-type;
description
"AH header type.";
}
identity routing {
base protocol-type;
description
"Routing IPv6 header type.";
}
identity esp {
base protocol-type;
description
"ESP header type.";
}
identity ah {
base protocol-type;
description
"AH header type.";
}
/* Groupings */
/* Groupings */
grouping vpn-service-cloud-access {
container cloud-accesses {
if-feature cloud-access;
list cloud-access {
grouping vpn-service-cloud-access {
container cloud-accesses {
if-feature cloud-access;
list cloud-access {
key cloud-identifier;
密钥云标识符；
leaf cloud-identifier {
type string;
description
"Identification of cloud service.
Local administration meaning.";
}
choice list-flavor {
case permit-any {
leaf permit-any {
type empty;
description
"Allows all sites.";
}
}
case deny-any-except {
leaf-list permit-site {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID to be authorized.";
}
}
leaf cloud-identifier {
type string;
description
"Identification of cloud service.
Local administration meaning.";
}
choice list-flavor {
case permit-any {
leaf permit-any {
type empty;
description
"Allows all sites.";
}
}
case deny-any-except {
leaf-list permit-site {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID to be authorized.";
}
}
case permit-any-except {
leaf-list deny-site {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID to be denied.";
}
}
description
"Choice for cloud access policy.";
}
container authorized-sites {
list authorized-site {
key site-id;
case permit-any-except {
leaf-list deny-site {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID to be denied.";
}
}
description
"Choice for cloud access policy.";
}
container authorized-sites {
list authorized-site {
key site-id;
leaf site-id {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID.";
}
description
"List of authorized sites.";
}
description
"Configuration of authorized sites.";
}
container denied-sites {
list denied-site {
key site-id;
leaf site-id {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID.";
}
description
"List of authorized sites.";
}
description
"Configuration of authorized sites.";
}
container denied-sites {
list denied-site {
key site-id;
leaf site-id {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID.";
}
description
"List of denied sites.";
}
description
"Configuration of denied sites.";
}
leaf site-id {
type leafref {
path "/l3vpn-svc/sites/site/site-id";
}
description
"Site ID.";
}
description
"List of denied sites.";
}
description
"Configuration of denied sites.";
}
container address-translation {
container nat44 {
leaf enabled {
type boolean;
default false;
description
"Controls whether or not address translation is required.";
}
leaf nat44-customer-address {
type inet:ipv4-address;
must "../enabled = 'true'" {
description
"Applicable only if address translation is enabled.";
}
description
"Address to be used for translation.
This is to be used if the customer is
providing the address.";
}
description
"IPv4-to-IPv4 translation.";
}
description
"Container for NAT.";
}
description
"Cloud access configuration.";
}
description
"Container for cloud access configurations.";
}
description
"Grouping for VPN cloud definition.";
}
container address-translation {
container nat44 {
leaf enabled {
type boolean;
default false;
description
"Controls whether or not address translation is required.";
}
leaf nat44-customer-address {
type inet:ipv4-address;
must "../enabled = 'true'" {
description
"Applicable only if address translation is enabled.";
}
description
"Address to be used for translation.
This is to be used if the customer is
providing the address.";
}
description
"IPv4-to-IPv4 translation.";
}
description
"Container for NAT.";
}
description
"Cloud access configuration.";
}
description
"Container for cloud access configurations.";
}
description
"Grouping for VPN cloud definition.";
}
grouping multicast-rp-group-cfg {
choice group-format {
case startend {
leaf group-start {
type inet:ip-address;
description
"First group address.";
}
leaf group-end {
type inet:ip-address;
description
"Last group address.";
}
}
case singleaddress {
leaf group-address {
type inet:ip-address;
description
"Group address.";
}
}
description
"Choice for group format.";
}
description
"Definition of groups for RP-to-group mapping.";
}
grouping multicast-rp-group-cfg {
choice group-format {
case startend {
leaf group-start {
type inet:ip-address;
description
"First group address.";
}
leaf group-end {
type inet:ip-address;
description
"Last group address.";
}
}
case singleaddress {
leaf group-address {
type inet:ip-address;
description
"Group address.";
}
}
description
"Choice for group format.";
}
description
"Definition of groups for RP-to-group mapping.";
}
grouping vpn-service-multicast {
container multicast {
if-feature multicast;
leaf enabled {
type boolean;
default false;
description
"Enables multicast.";
}
container customer-tree-flavors {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
description
"Type of trees used by customer.";
}
grouping vpn-service-multicast {
container multicast {
if-feature multicast;
leaf enabled {
type boolean;
default false;
description
"Enables multicast.";
}
container customer-tree-flavors {
leaf-list tree-flavor {
type identityref {
base multicast-tree-type;
}
description
"Type of tree to be used.";
}
description
"Type of trees used by customer.";
}
container rp {
container rp-group-mappings {
list rp-group-mapping {
key id;
container rp {
container rp-group-mappings {
list rp-group-mapping {
key id;
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
leaf enabled {
type boolean;
default false;
description
"Set to true if the RP must be a provider-managed node.
Set to false if it is a customer-managed node.";
}
leaf rp-redundancy {
when "../enabled = 'true'" {
description
"Relevant when the RP is provider-managed.";
}
type boolean;
default false;
description
"If true, a redundancy mechanism for the RP is required.";
}
leaf optimal-traffic-delivery {
when "../enabled = 'true'" {
description
"Relevant when the RP is provider-managed.";
}
type boolean;
default false;
description
"If true, the SP must ensure that
traffic uses an optimal path.";
}
description
"Parameters for a provider-managed RP.";
}
leaf id {
type uint16;
description
"Unique identifier for the mapping.";
}
container provider-managed {
leaf enabled {
type boolean;
default false;
description
"Set to true if the RP must be a provider-managed node.
Set to false if it is a customer-managed node.";
}
leaf rp-redundancy {
when "../enabled = 'true'" {
description
"Relevant when the RP is provider-managed.";
}
type boolean;
default false;
description
"If true, a redundancy mechanism for the RP is required.";
}
leaf optimal-traffic-delivery {
when "../enabled = 'true'" {
description
"Relevant when the RP is provider-managed.";
}
type boolean;
default false;
description
"If true, the SP must ensure that
traffic uses an optimal path.";
}
description
"Parameters for a provider-managed RP.";
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is provider-managed.";
}
type inet:ip-address;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
leaf rp-address {
when "../provider-managed/enabled = 'false'" {
description
"Relevant when the RP is provider-managed.";
}
type inet:ip-address;
description
"Defines the address of the RP.
Used if the RP is customer-managed.";
}
container groups {
list group {
key id;
container groups {
list group {
key id;
leaf id {
type uint16;
description
"Identifier for the group.";
}
uses multicast-rp-group-cfg;
description
"List of groups.";
}
leaf id {
type uint16;
description
"Identifier for the group.";
}
uses multicast-rp-group-cfg;
description
"List of groups.";
}
description
"Multicast groups associated with the RP.";
}
description
"Multicast groups associated with the RP.";
}
description
"List of RP-to-group mappings.";
}
description
"RP-to-group mappings.";
}
container rp-discovery {
leaf rp-discovery-type {
type identityref {
base multicast-rp-discovery-type;
}
default static-rp;
description
"Type of RP discovery used.";
}
description
"List of RP-to-group mappings.";
}
description
"RP-to-group mappings.";
}
container rp-discovery {
leaf rp-discovery-type {
type identityref {
base multicast-rp-discovery-type;
}
default static-rp;
description
"Type of RP discovery used.";
}
container bsr-candidates {
when "../rp-discovery-type = 'bsr-rp'" {
description
"Only applicable if discovery type is BSR-RP.";
}
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Address of BSR candidate.";
}
description
"Customer BSR candidate's address.";
}
description
"RP discovery parameters.";
}
container bsr-candidates {
when "../rp-discovery-type = 'bsr-rp'" {
description
"Only applicable if discovery type is BSR-RP.";
}
leaf-list bsr-candidate-address {
type inet:ip-address;
description
"Address of BSR candidate.";
}
description
"Customer BSR candidate's address.";
}
description
"RP discovery parameters.";
}
description
"RP parameters.";
}
description
"Multicast global parameters for the VPN service.";
}
description
"Grouping for multicast VPN definition.";
}
description
"RP parameters.";
}
description
"Multicast global parameters for the VPN service.";
}
description
"Grouping for multicast VPN definition.";
}
grouping vpn-service-mpls {
leaf carrierscarrier {
if-feature carrierscarrier;
type boolean;
default false;
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"Grouping for MPLS CsC definition.";
}
grouping vpn-service-mpls {
leaf carrierscarrier {
if-feature carrierscarrier;
type boolean;
default false;
description
"The VPN is using CsC, and so MPLS is required.";
}
description
"Grouping for MPLS CsC definition.";
}
grouping customer-location-info {
container locations {
list location {
key location-id;
grouping customer-location-info {
container locations {
list location {
key location-id;
leaf location-id {
type svc-id;
description
"Identifier for a particular location.";
}
leaf address {
type string;
description
"Address (number and street) of the site.";
}
leaf postal-code {
type string;
description
"Postal code of the site.";
}
leaf state {
type string;
description
"State of the site. This leaf can also be used to describe
a region for a country that does not have states.";
}
leaf city {
type string;
description
"City of the site.";
}
leaf country-code {
type string {
pattern '[A-Z]{2}';
}
description
"Country of the site.
Expressed as ISO ALPHA-2 code.";
}
description
"Location of the site.";
}
description
"List of locations for the site.";
}
description
"This grouping defines customer location parameters.";
}
leaf location-id {
type svc-id;
description
"Identifier for a particular location.";
}
leaf address {
type string;
description
"Address (number and street) of the site.";
}
leaf postal-code {
type string;
description
"Postal code of the site.";
}
leaf state {
type string;
description
"State of the site. This leaf can also be used to describe
a region for a country that does not have states.";
}
leaf city {
type string;
description
"City of the site.";
}
leaf country-code {
type string {
pattern '[A-Z]{2}';
}
description
"Country of the site.
Expressed as ISO ALPHA-2 code.";
}
description
"Location of the site.";
}
description
"List of locations for the site.";
}
description
"This grouping defines customer location parameters.";
}
grouping site-group {
container groups {
list group {
key group-id;
grouping site-group {
container groups {
list group {
key group-id;
leaf group-id {
type string;
description
"Group-id the site belongs to.";
}
description
"List of group-ids.";
}
description
"Groups the site or site-network-access belongs to.";
}
description
"Grouping definition to assign
group-ids to site or site-network-access.";
}
grouping site-diversity {
container site-diversity {
if-feature site-diversity;
leaf group-id {
type string;
description
"Group-id the site belongs to.";
}
description
"List of group-ids.";
}
description
"Groups the site or site-network-access belongs to.";
}
description
"Grouping definition to assign
group-ids to site or site-network-access.";
}
grouping site-diversity {
container site-diversity {
if-feature site-diversity;
uses site-group;
使用网站组；
description
"Diversity constraint type.
All site-network-accesses will inherit the group values
defined here.";
}
description
"This grouping defines site diversity parameters.";
}
grouping access-diversity {
container access-diversity {
if-feature site-diversity;
description
"Diversity constraint type.
All site-network-accesses will inherit the group values
defined here.";
}
description
"This grouping defines site diversity parameters.";
}
grouping access-diversity {
container access-diversity {
if-feature site-diversity;
uses site-group;
使用网站组；
container constraints {
list constraint {
key constraint-type;
container constraints {
list constraint {
key constraint-type;
leaf constraint-type {
type identityref {
base placement-diversity;
}
description
"Diversity constraint type.";
}
container target {
choice target-flavor {
case id {
list group {
key group-id;
leaf constraint-type {
type identityref {
base placement-diversity;
}
description
"Diversity constraint type.";
}
container target {
choice target-flavor {
case id {
list group {
key group-id;
leaf group-id {
type string;
description
"The constraint will be applied against
this particular group-id.";
}
description
"List of groups.";
}
}
case all-accesses {
leaf all-other-accesses {
type empty;
description
"The constraint will be applied against
all other site network accesses of this site.";
}
}
case all-groups {
leaf all-other-groups {
type empty;
description
"The constraint will be applied against
all other groups managed by the customer.";
}
}
description
"Choice for the group definition.";
}
leaf group-id {
type string;
description
"The constraint will be applied against
this particular group-id.";
}
description
"List of groups.";
}
}
case all-accesses {
leaf all-other-accesses {
type empty;
description
"The constraint will be applied against
all other site network accesses of this site.";
}
}
case all-groups {
leaf all-other-groups {
type empty;
description
"The constraint will be applied against
all other groups managed by the customer.";
}
}
description
"Choice for the group definition.";
}
description
"The constraint will be applied against
this list of groups.";
}
description
"List of constraints.";
}
description
"Placement constraints for this site network access.";
}
description
"The constraint will be applied against
this list of groups.";
}
description
"List of constraints.";
}
description
"Placement constraints for this site network access.";
}
description
"Diversity parameters.";
}
description
"This grouping defines access diversity parameters.";
}
description
"Diversity parameters.";
}
description
"This grouping defines access diversity parameters.";
}
grouping operational-requirements {
leaf requested-site-start {
type yang:date-and-time;
description
"Optional leaf indicating requested date and time when the
service at a particular site is expected to start.";
}
grouping operational-requirements {
leaf requested-site-start {
type yang:date-and-time;
description
"Optional leaf indicating requested date and time when the
service at a particular site is expected to start.";
}
leaf requested-site-stop {
type yang:date-and-time;
description
"Optional leaf indicating requested date and time when the
service at a particular site is expected to stop.";
}
description
"This grouping defines some operational parameters.";
}
leaf requested-site-stop {
type yang:date-and-time;
description
"Optional leaf indicating requested date and time when the
service at a particular site is expected to stop.";
}
description
"This grouping defines some operational parameters.";
}
grouping operational-requirements-ops {
leaf actual-site-start {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and time when the
service at a particular site actually started.";
}
leaf actual-site-stop {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and time when the
service at a particular site actually stopped.";
}
description
"This grouping defines some operational parameters.";
}
grouping operational-requirements-ops {
leaf actual-site-start {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and time when the
service at a particular site actually started.";
}
leaf actual-site-stop {
type yang:date-and-time;
config false;
description
"Optional leaf indicating actual date and time when the
service at a particular site actually stopped.";
}
description
"This grouping defines some operational parameters.";
}
grouping flow-definition {
container match-flow {
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1p {
type uint8 {
range "0..7";
}
description
"802.1p matching.";
}
leaf ipv4-src-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 src address.";
}
leaf ipv6-src-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 src address.";
}
leaf ipv4-dst-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 dst address.";
}
grouping flow-definition {
container match-flow {
leaf dscp {
type inet:dscp;
description
"DSCP value.";
}
leaf dot1p {
type uint8 {
range "0..7";
}
description
"802.1p matching.";
}
leaf ipv4-src-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 src address.";
}
leaf ipv6-src-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 src address.";
}
leaf ipv4-dst-prefix {
type inet:ipv4-prefix;
description
"Match on IPv4 dst address.";
}
leaf ipv6-dst-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 dst address.";
}
leaf l4-src-port {
type inet:port-number;
description
"Match on Layer 4 src port.";
}
leaf-list target-sites {
type svc-id;
description
"Identify a site as traffic destination.";
}
container l4-src-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary must be higher than lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 src port range.";
}
leaf l4-dst-port {
type inet:port-number;
description
"Match on Layer 4 dst port.";
}
container l4-dst-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf ipv6-dst-prefix {
type inet:ipv6-prefix;
description
"Match on IPv6 dst address.";
}
leaf l4-src-port {
type inet:port-number;
description
"Match on Layer 4 src port.";
}
leaf-list target-sites {
type svc-id;
description
"Identify a site as traffic destination.";
}
container l4-src-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary must be higher than lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 src port range.";
}
leaf l4-dst-port {
type inet:port-number;
description
"Match on Layer 4 dst port.";
}
container l4-dst-port-range {
leaf lower-port {
type inet:port-number;
description
"Lower boundary for port.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary must be higher than lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 dst port range.";
}
leaf protocol-field {
type union {
type uint8;
type identityref {
base protocol-type;
}
}
description
"Match on IPv4 protocol or IPv6 Next Header field.";
}
leaf upper-port {
type inet:port-number;
must ". >= ../lower-port" {
description
"Upper boundary must be higher than lower boundary.";
}
description
"Upper boundary for port.";
}
description
"Match on Layer 4 dst port range.";
}
leaf protocol-field {
type union {
type uint8;
type identityref {
base protocol-type;
}
}
description
"Match on IPv4 protocol or IPv6 Next Header field.";
}
description
"Describes flow-matching criteria.";
}
description
"Flow definition based on criteria.";
}
grouping site-service-basic {
leaf svc-input-bandwidth {
type uint32;
units bps;
description
"From the PE's perspective, the service input
bandwidth of the connection.";
}
leaf svc-output-bandwidth {
type uint32;
units bps;
description
"From the PE's perspective, the service output
bandwidth of the connection.";
}
description
"Describes flow-matching criteria.";
}
description
"Flow definition based on criteria.";
}
grouping site-service-basic {
leaf svc-input-bandwidth {
type uint32;
units bps;
description
"From the PE's perspective, the service input
bandwidth of the connection.";
}
leaf svc-output-bandwidth {
type uint32;
units bps;
description
"From the PE's perspective, the service output
bandwidth of the connection.";
}
leaf svc-mtu {
type uint16;
units bytes;
description
"MTU at service level. If the service is IP,
it refers to the IP MTU.";
}
description
"Defines basic service parameters for a site.";
}
grouping site-protection {
container traffic-protection {
if-feature fast-reroute;
leaf enabled {
type boolean;
default false;
description
"Enables traffic protection of access link.";
}
description
"Fast Reroute service parameters for the site.";
}
description
"Defines protection service parameters for a site.";
}
grouping site-service-mpls {
container carrierscarrier {
if-feature carrierscarrier;
leaf signalling-type {
type enumeration {
enum "ldp" {
description
"Use LDP as the signalling protocol
between the PE and the CE.";
}
enum "bgp" {
description
"Use BGP (as per RFC 3107) as the signalling protocol
between the PE and the CE.
In this case, BGP must also be configured as
the routing protocol.";
}
}
description
"MPLS signalling type.";
}
leaf svc-mtu {
type uint16;
units bytes;
description
"MTU at service level. If the service is IP,
it refers to the IP MTU.";
}
description
"Defines basic service parameters for a site.";
}
grouping site-protection {
container traffic-protection {
if-feature fast-reroute;
leaf enabled {
type boolean;
default false;
description
"Enables traffic protection of access link.";
}
description
"Fast Reroute service parameters for the site.";
}
description
"Defines protection service parameters for a site.";
}
grouping site-service-mpls {
container carrierscarrier {
if-feature carrierscarrier;
leaf signalling-type {
type enumeration {
enum "ldp" {
description
"Use LDP as the signalling protocol
between the PE and the CE.";
}
enum "bgp" {
description
"Use BGP (as per RFC 3107) as the signalling protocol
between the PE and the CE.
In this case, BGP must also be configured as
the routing protocol.";
}
}
description
"MPLS signalling type.";
}
description
"This container is used when the customer provides
MPLS-based services. This is used in the case of CsC.";
}
description
"Defines MPLS service parameters for a site.";
}
grouping site-service-qos-profile {
container qos {
if-feature qos;
container qos-classification-policy {
list rule {
key id;
ordered-by user;
description
"This container is used when the customer provides
MPLS-based services. This is used in the case of CsC.";
}
description
"Defines MPLS service parameters for a site.";
}
grouping site-service-qos-profile {
container qos {
if-feature qos;
container qos-classification-policy {
list rule {
key id;
ordered-by user;
leaf id {
type uint16;
description
"ID of the rule.";
}
leaf id {
type uint16;
description
"ID of the rule.";
}
choice match-type {
case match-flow {
uses flow-definition;
}
case match-application {
leaf match-application {
type identityref {
base customer-application;
}
description
"Defines the application to match.";
}
}
description
"Choice for classification.";
}
choice match-type {
case match-flow {
uses flow-definition;
}
case match-application {
leaf match-application {
type identityref {
base customer-application;
}
description
"Defines the application to match.";
}
}
description
"Choice for classification.";
}
leaf target-class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
}
leaf target-class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
}
description
"List of marking rules.";
}
description
"List of marking rules.";
}
description
"Configuration of the traffic classification policy.";
}
container qos-profile {
description
"Configuration of the traffic classification policy.";
}
container qos-profile {
choice qos-profile {
description
"Choice for QoS profile.
Can be standard profile or custom.";
case standard {
leaf profile {
type string;
description
"QoS profile to be used.";
}
}
case custom {
container classes {
if-feature qos-custom;
list class {
key class-id;
choice qos-profile {
description
"Choice for QoS profile.
Can be standard profile or custom.";
case standard {
leaf profile {
type string;
description
"QoS profile to be used.";
}
}
case custom {
container classes {
if-feature qos-custom;
list class {
key class-id;
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
}
leaf rate-limit {
type uint8;
units percent;
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service bandwidth.";
}
container latency {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should use the path with the
lowest latency.";
}
}
leaf class-id {
type string;
description
"Identification of the class of service.
This identifier is internal to the administration.";
}
leaf rate-limit {
type uint8;
units percent;
description
"To be used if the class must be rate-limited.
Expressed as percentage of the service bandwidth.";
}
container latency {
choice flavor {
case lowest {
leaf use-lowest-latency {
type empty;
description
"The traffic class should use the path with the
lowest latency.";
}
}
case boundary {
leaf latency-boundary {
type uint16;
units msec;
description
"The traffic class should use a path with a
defined maximum latency.";
}
}
description
"Latency constraint on the traffic class.";
}
description
"Latency constraint on the traffic class.";
}
container jitter {
choice flavor {
case lowest {
leaf use-lowest-jitter {
type empty;
description
"The traffic class should use the path with the
lowest jitter.";
}
}
case boundary {
leaf latency-boundary {
type uint32;
units usec;
description
"The traffic class should use a path with a
defined maximum jitter.";
}
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type uint8;
units percent;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service bandwidth.";
}
case boundary {
leaf latency-boundary {
type uint16;
units msec;
description
"The traffic class should use a path with a
defined maximum latency.";
}
}
description
"Latency constraint on the traffic class.";
}
description
"Latency constraint on the traffic class.";
}
container jitter {
choice flavor {
case lowest {
leaf use-lowest-jitter {
type empty;
description
"The traffic class should use the path with the
lowest jitter.";
}
}
case boundary {
leaf latency-boundary {
type uint32;
units usec;
description
"The traffic class should use a path with a
defined maximum jitter.";
}
}
description
"Jitter constraint on the traffic class.";
}
description
"Jitter constraint on the traffic class.";
}
container bandwidth {
leaf guaranteed-bw-percent {
type uint8;
units percent;
description
"To be used to define the guaranteed bandwidth
as a percentage of the available service bandwidth.";
}
leaf end-to-end {
type empty;
description
"Used if the bandwidth reservation
must be done on the MPLS network too.";
}
description
"Bandwidth constraint on the traffic class.";
}
description
"List of classes of services.";
}
description
"Container for list of classes of services.";
}
leaf end-to-end {
type empty;
description
"Used if the bandwidth reservation
must be done on the MPLS network too.";
}
description
"Bandwidth constraint on the traffic class.";
}
description
"List of classes of services.";
}
description
"Container for list of classes of services.";
}
}
}
}
description
"QoS profile configuration.";
}
description
"QoS configuration.";
}
description
"This grouping defines QoS parameters for a site.";
}
}
description
"QoS profile configuration.";
}
description
"QoS configuration.";
}
description
"This grouping defines QoS parameters for a site.";
}
grouping site-security-authentication {
container authentication {
description
"Authentication parameters.";
}
description
"This grouping defines authentication parameters for a site.";
grouping site-security-authentication {
container authentication {
description
"Authentication parameters.";
}
description
"This grouping defines authentication parameters for a site.";
}
grouping site-security-encryption {
container encryption {
if-feature encryption;
leaf enabled {
type boolean;
default false;
description
"If true, access encryption is required.";
}
}
grouping site-security-encryption {
container encryption {
if-feature encryption;
leaf enabled {
type boolean;
default false;
description
"If true, access encryption is required.";
}
leaf layer {
type enumeration {
enum layer2 {
description
"Encryption will occur at Layer 2.";
}
enum layer3 {
description
"Encryption will occur at Layer 3.
For example, IPsec may be used.";
}
}
mandatory true;
description
"Layer on which encryption is applied.";
}
container encryption-profile {
choice profile {
case provider-profile {
leaf profile-name {
type string;
description
"Name of the SP profile to be applied.";
}
}
case customer-profile {
leaf algorithm {
type string;
description
"Encryption algorithm to be used.";
}
choice key-type {
case psk {
leaf preshared-key {
type string;
description
"Key coming from customer.";
}
}
case pki {
leaf layer {
type enumeration {
enum layer2 {
description
"Encryption will occur at Layer 2.";
}
enum layer3 {
description
"Encryption will occur at Layer 3.
For example, IPsec may be used.";
}
}
mandatory true;
description
"Layer on which encryption is applied.";
}
container encryption-profile {
choice profile {
case provider-profile {
leaf profile-name {
type string;
description
"Name of the SP profile to be applied.";
}
}
case customer-profile {
leaf algorithm {
type string;
description
"Encryption algorithm to be used.";
}
choice key-type {
case psk {
leaf preshared-key {
type string;
description
"Key coming from customer.";
}
}
case pki {
}
description
"Type of keys to be used.";
}
}
}
description
"Type of keys to be used.";
}
}
description
"Choice of profile.";
}
description
"Profile of encryption to be applied.";
}
description
"Encryption parameters.";
}
description
"This grouping defines encryption parameters for a site.";
}
description
"Choice of profile.";
}
description
"Profile of encryption to be applied.";
}
description
"Encryption parameters.";
}
description
"This grouping defines encryption parameters for a site.";
}
grouping site-attachment-bearer {
container bearer {
container requested-type {
if-feature requested-type;
leaf requested-type {
type string;
description
"Type of requested bearer: Ethernet, DSL,
Wireless, etc. Operator specific.";
}
leaf strict {
type boolean;
default false;
description
"Defines whether requested-type is a preference
or a strict requirement.";
}
description
"Container for requested-type.";
}
leaf always-on {
if-feature always-on;
type boolean;
default true;
description
"Request for an always-on access type.
For example, this could mean no dial access type.";
}
leaf bearer-reference {
if-feature bearer-reference;
type string;
description
"This is an internal reference for the SP.";
}
grouping site-attachment-bearer {
container bearer {
container requested-type {
if-feature requested-type;
leaf requested-type {
type string;
description
"Type of requested bearer: Ethernet, DSL,
Wireless, etc. Operator specific.";
}
leaf strict {
type boolean;
default false;
description
"Defines whether requested-type is a preference
or a strict requirement.";
}
description
"Container for requested-type.";
}
leaf always-on {
if-feature always-on;
type boolean;
default true;
description
"Request for an always-on access type.
For example, this could mean no dial access type.";
}
leaf bearer-reference {
if-feature bearer-reference;
type string;
description
"This is an internal reference for the SP.";
}
description
"Bearer-specific parameters.
To be augmented.";
}
description
"Defines physical properties of a site attachment.";
}
description
"Bearer-specific parameters.
To be augmented.";
}
description
"Defines physical properties of a site attachment.";
}
grouping site-routing {
container routing-protocols {
list routing-protocol {
key type;
grouping site-routing {
container routing-protocols {
list routing-protocol {
key type;
leaf type {
type identityref {
base routing-protocol-type;
}
description
"Type of routing protocol.";
}
leaf type {
type identityref {
base routing-protocol-type;
}
description
"Type of routing protocol.";
}
container ospf {
when "../type = 'ospf'" {
description
"Only applies when protocol is OSPF.";
}
if-feature rtg-ospf;
leaf-list address-family {
type address-family;
container ospf {
when "../type = 'ospf'" {
description
"Only applies when protocol is OSPF.";
}
if-feature rtg-ospf;
leaf-list address-family {
type address-family;
description
"Address family to be activated.";
}
leaf area-address {
type yang:dotted-quad;
description
"Area address.";
}
leaf metric {
type uint16;
description
"Metric of the PE-CE link.";
}
description
"Address family to be activated.";
}
leaf area-address {
type yang:dotted-quad;
description
"Area address.";
}
leaf metric {
type uint16;
description
"Metric of the PE-CE link.";
}
container sham-links {
if-feature rtg-ospf-sham-link;
list sham-link {
key target-site;
container sham-links {
if-feature rtg-ospf-sham-link;
list sham-link {
key target-site;
leaf target-site {
type svc-id;
description
"Target site for the sham link connection.
The site is referred to by its ID.";
}
leaf metric {
type uint16;
description
"Metric of the sham link.";
}
description
"Creates a sham link with another site.";
}
description
"List of sham links.";
}
description
"OSPF-specific configuration.";
}
leaf target-site {
type svc-id;
description
"Target site for the sham link connection.
The site is referred to by its ID.";
}
leaf metric {
type uint16;
description
"Metric of the sham link.";
}
description
"Creates a sham link with another site.";
}
description
"List of sham links.";
}
description
"OSPF-specific configuration.";
}
container bgp {
集装箱bgp{
when "../type = 'bgp'" {
description
"Only applies when protocol is BGP.";
}
if-feature rtg-bgp;
leaf autonomous-system {
type uint32;
description
"AS number.";
}
leaf-list address-family {
type address-family;
when "../type = 'bgp'" {
description
"Only applies when protocol is BGP.";
}
if-feature rtg-bgp;
leaf autonomous-system {
type uint32;
description
"AS number.";
}
leaf-list address-family {
type address-family;
description
"Address family to be activated.";
}
description
"BGP-specific configuration.";
}
description
"Address family to be activated.";
}
description
"BGP-specific configuration.";
}
container static {
when "../type = 'static'" {
description
"Only applies when protocol is static.";
}
container static {
when "../type = 'static'" {
description
"Only applies when protocol is static.";
}
container cascaded-lan-prefixes {
list ipv4-lan-prefixes {
if-feature ipv4;
key "lan next-hop";
container cascaded-lan-prefixes {
list ipv4-lan-prefixes {
if-feature ipv4;
key "lan next-hop";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv4-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
list ipv6-lan-prefixes {
if-feature ipv6;
key "lan next-hop";
leaf lan {
type inet:ipv4-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv4-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
list ipv6-lan-prefixes {
if-feature ipv6;
key "lan next-hop";
leaf lan {
type inet:ipv6-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv6-address;
description
"Next-hop address to use on the customer side.";
}
leaf lan {
type inet:ipv6-prefix;
description
"LAN prefixes.";
}
leaf lan-tag {
type string;
description
"Internal tag to be used in VPN policies.";
}
leaf next-hop {
type inet:ipv6-address;
description
"Next-hop address to use on the customer side.";
}
description
"List of LAN prefixes for the site.";
}
description
"LAN prefixes from the customer.";
}
description
"Configuration specific to static routing.";
}
container rip {
description
"List of LAN prefixes for the site.";
}
description
"LAN prefixes from the customer.";
}
description
"Configuration specific to static routing.";
}
container rip {
when "../type = 'rip'" {
description
"Only applies when protocol is RIP.";
}
if-feature rtg-rip;
leaf-list address-family {
type address-family;
when "../type = 'rip'" {
description
"Only applies when protocol is RIP.";
}
if-feature rtg-rip;
leaf-list address-family {
type address-family;
description
"Address family to be activated.";
}
description
"Address family to be activated.";
}
description
"Configuration specific to RIP routing.";
}
description
"Configuration specific to RIP routing.";
}
container vrrp {
集装箱vrrp{
when "../type = 'vrrp'" {
description
"Only applies when protocol is VRRP.";
}
if-feature rtg-vrrp;
leaf-list address-family {
type address-family;
when "../type = 'vrrp'" {
description
"Only applies when protocol is VRRP.";
}
if-feature rtg-vrrp;
leaf-list address-family {
type address-family;
description
"Address family to be activated.";
}
description
"Configuration specific to VRRP routing.";
}
description
"Address family to be activated.";
}
description
"Configuration specific to VRRP routing.";
}
description
"List of routing protocols used on
the site. This list can be augmented.";
}
description
"List of routing protocols used on
the site. This list can be augmented.";
}
description
"Defines routing protocols.";
}
description
"Grouping for routing protocols.";
}
description
"Defines routing protocols.";
}
description
"Grouping for routing protocols.";
}
grouping site-attachment-ip-connection {
container ip-connection {
container ipv4 {
if-feature ipv4;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
default "static-address";
description
"Defines how addresses are allocated.";
}
grouping site-attachment-ip-connection {
container ip-connection {
container ipv4 {
if-feature ipv4;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
default "static-address";
description
"Defines how addresses are allocated.";
}
leaf number-of-dynamic-address {
when "../address-allocation-type = 'provider-dhcp'" {
description
"Only applies when addresses are allocated by DHCP.";
}
type uint8;
default 1;
description
"Describes the number of IP addresses the customer requires.";
}
container dhcp-relay {
when "../address-allocation-type = 'provider-dhcp-relay'" {
description
"Only applies when provider is required to implement
DHCP relay function.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
leaf number-of-dynamic-address {
when "../address-allocation-type = 'provider-dhcp'" {
description
"Only applies when addresses are allocated by DHCP.";
}
type uint8;
default 1;
description
"Describes the number of IP addresses the customer requires.";
}
container dhcp-relay {
when "../address-allocation-type = 'provider-dhcp-relay'" {
description
"Only applies when provider is required to implement
DHCP relay function.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv4-address;
description
"IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
container addresses {
when "../address-allocation-type = 'static-address'" {
description
"Only applies when protocol allocation type is static.";
}
leaf provider-address {
type inet:ipv4-address;
description
"Address of provider side.";
}
leaf customer-address {
type inet:ipv4-address;
description
"Address of customer side.";
}
leaf mask {
type uint8 {
range "0..31";
}
description
"Subnet mask expressed in bits.";
}
description
"Describes IP addresses used.";
}
container addresses {
when "../address-allocation-type = 'static-address'" {
description
"Only applies when protocol allocation type is static.";
}
leaf provider-address {
type inet:ipv4-address;
description
"Address of provider side.";
}
leaf customer-address {
type inet:ipv4-address;
description
"Address of customer side.";
}
leaf mask {
type uint8 {
range "0..31";
}
description
"Subnet mask expressed in bits.";
}
description
"Describes IP addresses used.";
}
description "IPv4-specific parameters.";
说明“IPv4特定参数。”；
}
container ipv6 {
if-feature ipv6;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
default "static-address";
description
"Defines how addresses are allocated.";
}
leaf number-of-dynamic-address {
when
"../address-allocation-type = 'provider-dhcp' "+
"or ../address-allocation-type "+
"= 'provider-dhcp-slaac'" {
description
"Only applies when addresses are allocated by DHCP.";
}
}
container ipv6 {
if-feature ipv6;
leaf address-allocation-type {
type identityref {
base address-allocation-type;
}
default "static-address";
description
"Defines how addresses are allocated.";
}
leaf number-of-dynamic-address {
when
"../address-allocation-type = 'provider-dhcp' "+
"or ../address-allocation-type "+
"= 'provider-dhcp-slaac'" {
description
"Only applies when addresses are allocated by DHCP.";
}
type uint8;
default 1;
description
"Describes the number of IP addresses the customer requires.";
}
container dhcp-relay {
when "../address-allocation-type = 'provider-dhcp-relay'" {
description
"Only applies when provider is required to implement
DHCP relay function.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv6-address;
description
"IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
container addresses {
when "../address-allocation-type = 'static-address'" {
description
"Only applies when protocol allocation type is static.";
}
leaf provider-address {
type inet:ipv6-address;
description
"Address of provider side.";
}
leaf customer-address {
type inet:ipv6-address;
description
"Address of customer side.";
}
leaf mask {
type uint8 {
range "0..127";
}
description
"Subnet mask expressed in bits.";
}
description
"Describes IP addresses used.";
}
type uint8;
default 1;
description
"Describes the number of IP addresses the customer requires.";
}
container dhcp-relay {
when "../address-allocation-type = 'provider-dhcp-relay'" {
description
"Only applies when provider is required to implement
DHCP relay function.";
}
container customer-dhcp-servers {
leaf-list server-ip-address {
type inet:ipv6-address;
description
"IP address of customer DHCP server.";
}
description
"Container for list of customer DHCP servers.";
}
description
"DHCP relay provided by operator.";
}
container addresses {
when "../address-allocation-type = 'static-address'" {
description
"Only applies when protocol allocation type is static.";
}
leaf provider-address {
type inet:ipv6-address;
description
"Address of provider side.";
}
leaf customer-address {
type inet:ipv6-address;
description
"Address of customer side.";
}
leaf mask {
type uint8 {
range "0..127";
}
description
"Subnet mask expressed in bits.";
}
description
"Describes IP addresses used.";
}
description "IPv6-specific parameters.";
说明“IPv6特定参数。”；
}
container oam {
container bfd {
if-feature bfd;
leaf enabled {
type boolean;
default false;
description
"BFD activation.";
}
}
container oam {
container bfd {
if-feature bfd;
leaf enabled {
type boolean;
default false;
description
"BFD activation.";
}
choice holdtime {
case profile {
leaf profile-name {
type string;
description
"Well-known SP profile.";
}
description
"Well-known SP profile.";
}
case fixed {
leaf fixed-value {
type uint32;
units msec;
description
"Expected holdtime expressed in msec.";
}
}
description
"Choice for holdtime flavor.";
}
description
"Container for BFD.";
}
description
"Defines the OAM mechanisms used on the connection.";
}
description
"Defines connection parameters.";
}
description
"This grouping defines IP connection parameters.";
}
choice holdtime {
case profile {
leaf profile-name {
type string;
description
"Well-known SP profile.";
}
description
"Well-known SP profile.";
}
case fixed {
leaf fixed-value {
type uint32;
units msec;
description
"Expected holdtime expressed in msec.";
}
}
description
"Choice for holdtime flavor.";
}
description
"Container for BFD.";
}
description
"Defines the OAM mechanisms used on the connection.";
}
description
"Defines connection parameters.";
}
description
"This grouping defines IP connection parameters.";
}
grouping site-service-multicast {
container multicast {
if-feature multicast;
leaf multicast-site-type {
type enumeration {
enum receiver-only {
description
"The site only has receivers.";
}
enum source-only {
description
"The site only has sources.";
}
enum source-receiver {
description
"The site has both sources and receivers.";
}
}
default "source-receiver";
description
"Type of multicast site.";
}
container multicast-address-family {
leaf ipv4 {
if-feature ipv4;
type boolean;
default true;
description
"Enables IPv4 multicast.";
}
leaf ipv6 {
if-feature ipv6;
type boolean;
default false;
description
"Enables IPv6 multicast.";
}
description
"Defines protocol to carry multicast.";
}
leaf protocol-type {
type enumeration {
enum host {
description
"Hosts are directly connected to the provider network.
Host protocols such as IGMP or MLD are required.";
}
grouping site-service-multicast {
container multicast {
if-feature multicast;
leaf multicast-site-type {
type enumeration {
enum receiver-only {
description
"The site only has receivers.";
}
enum source-only {
description
"The site only has sources.";
}
enum source-receiver {
description
"The site has both sources and receivers.";
}
}
default "source-receiver";
description
"Type of multicast site.";
}
container multicast-address-family {
leaf ipv4 {
if-feature ipv4;
type boolean;
default true;
description
"Enables IPv4 multicast.";
}
leaf ipv6 {
if-feature ipv6;
type boolean;
default false;
description
"Enables IPv6 multicast.";
}
description
"Defines protocol to carry multicast.";
}
leaf protocol-type {
type enumeration {
enum host {
description
"Hosts are directly connected to the provider network.
Host protocols such as IGMP or MLD are required.";
}
enum router {
description
"Hosts are behind a customer router.
PIM will be implemented.";
}
enum both {
description
"Some hosts are behind a customer router, and some others
are directly connected to the provider network.
Both host and routing protocols must be used.
Typically, IGMP and PIM will be implemented.";
}
}
default "both";
description
"Multicast protocol type to be used with the customer site.";
}
enum router {
description
"Hosts are behind a customer router.
PIM will be implemented.";
}
enum both {
description
"Some hosts are behind a customer router, and some others
are directly connected to the provider network.
Both host and routing protocols must be used.
Typically, IGMP and PIM will be implemented.";
}
}
default "both";
description
"Multicast protocol type to be used with the customer site.";
}
description
"Multicast parameters for the site.";
}
description
"Multicast parameters for the site.";
}
description
"Multicast parameters for the site.";
}
description
"Multicast parameters for the site.";
}
grouping site-management {
container management {
leaf type {
type identityref {
base management;
}
description
"Management type of the connection.";
}
description
"Management configuration.";
}
description
"Management parameters for the site.";
}
grouping site-management {
container management {
leaf type {
type identityref {
base management;
}
description
"Management type of the connection.";
}
description
"Management configuration.";
}
description
"Management parameters for the site.";
}
grouping site-devices {
container devices {
must "/l3vpn-svc/sites/site/management/type = "+
"'provider-managed' or "+
"/l3vpn-svc/sites/site/management/type = "+
"'co-managed'" {
description
"Applicable only for provider-managed or co-managed device.";
}
list device {
key device-id;
grouping site-devices {
container devices {
must "/l3vpn-svc/sites/site/management/type = "+
"'provider-managed' or "+
"/l3vpn-svc/sites/site/management/type = "+
"'co-managed'" {
description
"Applicable only for provider-managed or co-managed device.";
}
list device {
key device-id;
leaf device-id {
type svc-id;
description
"Identifier for the device.";
}
leaf location {
type leafref {
path "/l3vpn-svc/sites/site/locations/"+
"location/location-id";
}
description
"Location of the device.";
}
container management {
must "/l3vpn-svc/sites/site/management/type"+
"= 'co-managed'" {
description
"Applicable only for co-managed device.";
}
leaf address-family {
type address-family;
leaf device-id {
type svc-id;
description
"Identifier for the device.";
}
leaf location {
type leafref {
path "/l3vpn-svc/sites/site/locations/"+
"location/location-id";
}
description
"Location of the device.";
}
container management {
must "/l3vpn-svc/sites/site/management/type"+
"= 'co-managed'" {
description
"Applicable only for co-managed device.";
}
leaf address-family {
type address-family;
description
"Address family used for management.";
}
leaf address {
type inet:ip-address;
description
"Management address.";
}
description
"Management configuration. Applicable only for
co-managed device.";
}
description
"Address family used for management.";
}
leaf address {
type inet:ip-address;
description
"Management address.";
}
description
"Management configuration. Applicable only for
co-managed device.";
}
description
"Device configuration.";
}
description
"List of devices requested by customer.";
}
description
"Grouping for device allocation.";
}
grouping site-vpn-flavor {
leaf site-vpn-flavor {
type identityref {
base site-vpn-flavor;
}
default site-vpn-flavor-single;
description
"Defines whether the site is, for example,
a single VPN site or a multiVPN.";
}
description
"Grouping for site VPN flavor.";
}
description
"Device configuration.";
}
description
"List of devices requested by customer.";
}
description
"Grouping for device allocation.";
}
grouping site-vpn-flavor {
leaf site-vpn-flavor {
type identityref {
base site-vpn-flavor;
}
default site-vpn-flavor-single;
description
"Defines whether the site is, for example,
a single VPN site or a multiVPN.";
}
description
"Grouping for site VPN flavor.";
}
grouping site-vpn-policy {
container vpn-policies {
list vpn-policy {
key vpn-policy-id;
grouping site-vpn-policy {
container vpn-policies {
list vpn-policy {
key vpn-policy-id;
leaf vpn-policy-id {
type svc-id;
description
"Unique identifier for the VPN policy.";
}
leaf vpn-policy-id {
type svc-id;
description
"Unique identifier for the VPN policy.";
}
list entries {
key id;
list entries {
key id;
leaf id {
type svc-id;
description
"Unique identifier for the policy entry.";
}
leaf id {
type svc-id;
description
"Unique identifier for the policy entry.";
}
container filter {
choice lan {
case prefixes {
leaf-list ipv4-lan-prefix {
if-feature ipv4;
type inet:ipv4-prefix;
description
"List of IPv4 prefixes to be matched.";
}
leaf-list ipv6-lan-prefix {
if-feature ipv6;
type inet:ipv6-prefix;
description
"List of IPv6 prefixes to be matched.";
}
}
case lan-tag {
leaf-list lan-tag {
type string;
description
"List of 'lan-tag' items to be matched.";
}
}
description
"Choice of ways to do LAN matching.";
}
description
"If used, it permits the splitting of
site LANs among multiple VPNs.
If no filter is used, all the LANs will be
part of the same VPNs with the same role.";
}
container vpn {
leaf vpn-id {
type leafref {
path "/l3vpn-svc/vpn-services/"+
"vpn-service/vpn-id";
}
mandatory true;
description
"Reference to an IP VPN.";
}
container filter {
choice lan {
case prefixes {
leaf-list ipv4-lan-prefix {
if-feature ipv4;
type inet:ipv4-prefix;
description
"List of IPv4 prefixes to be matched.";
}
leaf-list ipv6-lan-prefix {
if-feature ipv6;
type inet:ipv6-prefix;
description
"List of IPv6 prefixes to be matched.";
}
}
case lan-tag {
leaf-list lan-tag {
type string;
description
"List of 'lan-tag' items to be matched.";
}
}
description
"Choice of ways to do LAN matching.";
}
description
"If used, it permits the splitting of
site LANs among multiple VPNs.
If no filter is used, all the LANs will be
part of the same VPNs with the same role.";
}
container vpn {
leaf vpn-id {
type leafref {
path "/l3vpn-svc/vpn-services/"+
"vpn-service/vpn-id";
}
mandatory true;
description
"Reference to an IP VPN.";
}
leaf site-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"Role of the site in the IP VPN.";
}
description
"List of VPNs the LAN is associated with.";
}
description
"List of entries for export policy.";
}
description
"List of VPN policies.";
}
description
"VPN policy.";
}
description
"VPN policy parameters for the site.";
}
leaf site-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"Role of the site in the IP VPN.";
}
description
"List of VPNs the LAN is associated with.";
}
description
"List of entries for export policy.";
}
description
"List of VPN policies.";
}
description
"VPN policy.";
}
description
"VPN policy parameters for the site.";
}
grouping site-maximum-routes {
container maximum-routes {
list address-family {
key af;
grouping site-maximum-routes {
container maximum-routes {
list address-family {
key af;
leaf af {
type address-family;
leaf af {
type address-family;
description
"Address family.";
}
leaf maximum-routes {
type uint32;
description
"Maximum prefixes the VRF can accept for this address family.";
}
description
"List of address families.";
}
description
"Address family.";
}
leaf maximum-routes {
type uint32;
description
"Maximum prefixes the VRF can accept for this address family.";
}
description
"List of address families.";
}
description
"Defines 'maximum-routes' for the VRF.";
}
description
"Defines 'maximum-routes' for the VRF.";
}
description
"Defines 'maximum-routes' for the site.";
}
description
"Defines 'maximum-routes' for the site.";
}
grouping site-security {
container security {
uses site-security-authentication;
uses site-security-encryption;
grouping site-security {
container security {
uses site-security-authentication;
uses site-security-encryption;
description
"Site-specific security parameters.";
}
description
"Grouping for security parameters.";
}
description
"Site-specific security parameters.";
}
description
"Grouping for security parameters.";
}
grouping site-service {
container service {
uses site-service-qos-profile;
uses site-service-mpls;
uses site-service-multicast;
grouping site-service {
container service {
uses site-service-qos-profile;
uses site-service-mpls;
uses site-service-multicast;
description
"Service parameters on the attachment.";
}
description
"Grouping for service parameters.";
}
description
"Service parameters on the attachment.";
}
description
"Grouping for service parameters.";
}
grouping site-network-access-service {
container service {
uses site-service-basic;
uses site-service-qos-profile;
uses site-service-mpls;
uses site-service-multicast;
grouping site-network-access-service {
container service {
uses site-service-basic;
uses site-service-qos-profile;
uses site-service-mpls;
uses site-service-multicast;
description
"Service parameters on the attachment.";
}
description
"Grouping for service parameters.";
}
description
"Service parameters on the attachment.";
}
description
"Grouping for service parameters.";
}
grouping vpn-extranet {
container extranet-vpns {
if-feature extranet-vpn;
list extranet-vpn {
key vpn-id;
grouping vpn-extranet {
container extranet-vpns {
if-feature extranet-vpn;
list extranet-vpn {
key vpn-id;
leaf vpn-id {
type svc-id;
description
"Identifies the target VPN.";
}
leaf local-sites-role {
type identityref {
base site-role;
leaf vpn-id {
type svc-id;
description
"Identifies the target VPN.";
}
leaf local-sites-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"This describes the role of the
local sites in the target VPN topology.";
}
description
"List of extranet VPNs the local VPN is attached to.";
}
description
"Container for extranet VPN configuration.";
}
description
"Grouping for extranet VPN configuration.
This provides an easy way to interconnect
all sites from two VPNs.";
}
}
default any-to-any-role;
description
"This describes the role of the
local sites in the target VPN topology.";
}
description
"List of extranet VPNs the local VPN is attached to.";
}
description
"Container for extranet VPN configuration.";
}
description
"Grouping for extranet VPN configuration.
This provides an easy way to interconnect
all sites from two VPNs.";
}
grouping site-attachment-availability {
container availability {
leaf access-priority {
type uint32;
default 1;
description
"Defines the priority for the access.
The higher the access-priority value,
the higher the preference of the access will be.";
}
description
"Availability parameters (used for multihoming).";
}
grouping site-attachment-availability {
container availability {
leaf access-priority {
type uint32;
default 1;
description
"Defines the priority for the access.
The higher the access-priority value,
the higher the preference of the access will be.";
}
description
"Availability parameters (used for multihoming).";
}
description
"Defines availability parameters for a site.";
}
description
"Defines availability parameters for a site.";
}
grouping access-vpn-policy {
container vpn-attachment {
grouping access-vpn-policy {
container vpn-attachment {
choice attachment-flavor {
case vpn-policy-id {
leaf vpn-policy-id {
type leafref {
path "/l3vpn-svc/sites/site/"+
"vpn-policies/vpn-policy/"+
"vpn-policy-id";
}
description
"Reference to a VPN policy.";
}
}
case vpn-id {
leaf vpn-id {
type leafref {
path "/l3vpn-svc/vpn-services"+
"/vpn-service/vpn-id";
}
description
"Reference to a VPN.";
}
leaf site-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"Role of the site in the IP VPN.";
}
}
mandatory true;
description
"Choice for VPN attachment flavor.";
}
description
"Defines VPN attachment of a site.";
}
description
"Defines the VPN attachment rules for a site's logical access.";
}
choice attachment-flavor {
case vpn-policy-id {
leaf vpn-policy-id {
type leafref {
path "/l3vpn-svc/sites/site/"+
"vpn-policies/vpn-policy/"+
"vpn-policy-id";
}
description
"Reference to a VPN policy.";
}
}
case vpn-id {
leaf vpn-id {
type leafref {
path "/l3vpn-svc/vpn-services"+
"/vpn-service/vpn-id";
}
description
"Reference to a VPN.";
}
leaf site-role {
type identityref {
base site-role;
}
default any-to-any-role;
description
"Role of the site in the IP VPN.";
}
}
mandatory true;
description
"Choice for VPN attachment flavor.";
}
description
"Defines VPN attachment of a site.";
}
description
"Defines the VPN attachment rules for a site's logical access.";
}
grouping vpn-svc-cfg {
leaf vpn-id {
type svc-id;
description
"VPN identifier. Local administration meaning.";
}
leaf customer-name {
type string;
description
"Name of the customer.";
}
leaf vpn-service-topology {
type identityref {
base vpn-topology;
}
default "any-to-any";
description
"VPN service topology.";
}
grouping vpn-svc-cfg {
leaf vpn-id {
type svc-id;
description
"VPN identifier. Local administration meaning.";
}
leaf customer-name {
type string;
description
"Name of the customer.";
}
leaf vpn-service-topology {
type identityref {
base vpn-topology;
}
default "any-to-any";
description
"VPN service topology.";
}
uses vpn-service-cloud-access;
uses vpn-service-multicast;
uses vpn-service-mpls;
uses vpn-extranet;
uses vpn-service-cloud-access;
uses vpn-service-multicast;
uses vpn-service-mpls;
uses vpn-extranet;
description
"Grouping for VPN service configuration.";
}
description
"Grouping for VPN service configuration.";
}
grouping site-top-level-cfg {
uses operational-requirements;
uses customer-location-info;
uses site-devices;
uses site-diversity;
uses site-management;
uses site-vpn-policy;
uses site-vpn-flavor;
uses site-maximum-routes;
uses site-security;
uses site-service;
uses site-protection;
uses site-routing;
grouping site-top-level-cfg {
uses operational-requirements;
uses customer-location-info;
uses site-devices;
uses site-diversity;
uses site-management;
uses site-vpn-policy;
uses site-vpn-flavor;
uses site-maximum-routes;
uses site-security;
uses site-service;
uses site-protection;
uses site-routing;
description
"Grouping for site top-level configuration.";
}
description
"Grouping for site top-level configuration.";
}
grouping site-network-access-top-level-cfg {
leaf site-network-access-type {
type identityref {
base site-network-access-type;
}
default "point-to-point";
description
"Describes the type of connection, e.g.,
point-to-point or multipoint.";
}
grouping site-network-access-top-level-cfg {
leaf site-network-access-type {
type identityref {
base site-network-access-type;
}
default "point-to-point";
description
"Describes the type of connection, e.g.,
point-to-point or multipoint.";
}
choice location-flavor {
case location {
when "/l3vpn-svc/sites/site/management/type = "+
"'customer-managed'" {
description
"Applicable only for customer-managed device.";
}
leaf location-reference {
type leafref {
path "/l3vpn-svc/sites/site/locations/"+
"location/location-id";
}
description
"Location of the site-network-access.";
}
}
case device {
when "/l3vpn-svc/sites/site/management/type = "+
"'provider-managed' or "+
"/l3vpn-svc/sites/site/management/type = "+
"'co-managed'" {
description
"Applicable only for provider-managed or co-managed device.";
}
leaf device-reference {
type leafref {
path "/l3vpn-svc/sites/site/devices/"+
"device/device-id";
}
description
"Identifier of CE to use.";
}
}
mandatory true;
description
"Choice of how to describe the site's location.";
}
choice location-flavor {
case location {
when "/l3vpn-svc/sites/site/management/type = "+
"'customer-managed'" {
description
"Applicable only for customer-managed device.";
}
leaf location-reference {
type leafref {
path "/l3vpn-svc/sites/site/locations/"+
"location/location-id";
}
description
"Location of the site-network-access.";
}
}
case device {
when "/l3vpn-svc/sites/site/management/type = "+
"'provider-managed' or "+
"/l3vpn-svc/sites/site/management/type = "+
"'co-managed'" {
description
"Applicable only for provider-managed or co-managed device.";
}
leaf device-reference {
type leafref {
path "/l3vpn-svc/sites/site/devices/"+
"device/device-id";
}
description
"Identifier of CE to use.";
}
}
mandatory true;
description
"Choice of how to describe the site's location.";
}
uses access-diversity;
uses site-attachment-bearer;
uses site-attachment-ip-connection;
uses site-security;
uses site-network-access-service;
uses site-routing;
uses site-attachment-availability;
uses access-vpn-policy;
uses access-diversity;
uses site-attachment-bearer;
uses site-attachment-ip-connection;
uses site-security;
uses site-network-access-service;
uses site-routing;
uses site-attachment-availability;
uses access-vpn-policy;
description
"Grouping for site network access top-level configuration.";
}
description
"Grouping for site network access top-level configuration.";
}
/* Main blocks */
/* Main blocks */
container l3vpn-svc {
container vpn-services {
list vpn-service {
key vpn-id;
container l3vpn-svc {
container vpn-services {
list vpn-service {
key vpn-id;
uses vpn-svc-cfg;
使用vpn-svc-cfg；
description
"List of VPN services.";
}
description
"Top-level container for the VPN services.";
}
description
"List of VPN services.";
}
description
"Top-level container for the VPN services.";
}
container sites {
list site {
key site-id;
container sites {
list site {
key site-id;
leaf site-id {
type svc-id;
description
"Identifier of the site.";
}
leaf site-id {
type svc-id;
description
"Identifier of the site.";
}
uses site-top-level-cfg;
uses operational-requirements-ops;
uses site-top-level-cfg;
uses operational-requirements-ops;
container site-network-accesses {
list site-network-access {
key site-network-access-id;
container site-network-accesses {
list site-network-access {
key site-network-access-id;
leaf site-network-access-id {
type svc-id;
description
"Identifier for the access.";
}
uses site-network-access-top-level-cfg;
leaf site-network-access-id {
type svc-id;
description
"Identifier for the access.";
}
uses site-network-access-top-level-cfg;
description
"List of accesses for a site.";
}
description
"List of accesses for a site.";
}
description
"List of accesses for a site.";
}
description
"List of accesses for a site.";
}
description
"List of sites.";
}
description
"Container for sites.";
}
description
"List of sites.";
}
description
"Container for sites.";
}
description
"Main container for L3VPN service configuration.";
}
description
"Main container for L3VPN service configuration.";
}
} <CODE ENDS>
}<代码结束>
The YANG module defined in this document MAY be accessed via the RESTCONF protocol [RFC8040] or the NETCONF protocol [RFC6241]. The lowest RESTCONF or NETCONF layer requires that the transport-layer protocol provide both data integrity and confidentiality; see Section 2 in [RFC8040] and Section 2 in [RFC6241]. The client MUST carefully examine the certificate presented by the server to determine if it meets the client's expectations, and the server MUST authenticate client access to any protected resource. The client identity derived from the authentication mechanism used is subject to the NETCONF Access Control Model (NACM) [RFC6536]. Other protocols that are used to access this YANG module are also required to support similar security mechanisms.
本文档中定义的模块可通过RESTCONF协议[RFC8040]或NETCONF协议[RFC6241]访问。最低的RESTCONF或NETCONF层要求传输层协议提供数据完整性和机密性；参见[RFC8040]中的第2节和[RFC6241]中的第2节。客户端必须仔细检查服务器提供的证书，以确定它是否满足客户端的期望，并且服务器必须验证客户端对任何受保护资源的访问。从所使用的身份验证机制派生的客户端标识受NETCONF访问控制模型（NACM）[RFC6536]的约束。用于访问此模块的其他协议也需要支持类似的安全机制。
The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be carefully created, read, updated, or deleted as appropriate. The entries in the lists below include customer-proprietary or confidential information; therefore, access to confidential information MUST be limited to authorized clients, and other clients MUST NOT be permitted to access the information.
必须仔细创建、读取、更新或删除“ietf-l3vpn-svc”模块中定义的数据节点（视情况而定）。以下列表中的条目包括客户专有或机密信息；因此，对机密信息的访问必须限于授权客户，其他客户不得访问该信息。
o /l3vpn-svc/vpn-services/vpn-service
o /l3vpn-svc/vpn-services/vpn-service
o /l3vpn-svc/sites/site
o /l3vpn-svc/sites/site
The data model proposes some security parameters than can be extended via augmentation as part of the customer service request; those parameters are described in Section 6.9.
数据模型提出了一些安全参数，这些参数可以作为客户服务请求的一部分通过扩充进行扩展；第6.9节描述了这些参数。
IANA has assigned a new URI from the "IETF XML Registry" [RFC3688].
IANA已从“IETF XML注册表”[RFC3688]分配了一个新的URI。
URI: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace.
URI:urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc注册人联系人：IESG xml:N/A；请求的URI是一个XML命名空间。
This document adds a new YANG module name in the "YANG Module Names" registry [RFC6020]:
本文档在“YANG模块名称”注册表[RFC6020]中添加新的YANG模块名称：
Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Reference: RFC 8049
Name: ietf-l3vpn-svc
Namespace: urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc
Prefix: l3vpn-svc
Reference: RFC 8049
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，DOI 10.17487/RFC3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, DOI 10.17487/RFC4026, March 2005, <http://www.rfc-editor.org/info/rfc4026>.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，DOI 10.17487/RFC4026，2005年3月<http://www.rfc-editor.org/info/rfc4026>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, <http://www.rfc-editor.org/info/rfc4577>.
[RFC4577]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“OSPF作为BGP/MPLS IP虚拟专用网络（VPN）的提供商/客户边缘协议”，RFC 4577，DOI 10.17487/RFC4577，2006年6月<http://www.rfc-editor.org/info/rfc4577>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <http://www.rfc-editor.org/info/rfc6020>.
[RFC6020]Bjorklund，M.，Ed.“YANG-网络配置协议的数据建模语言（NETCONF）”，RFC 6020，DOI 10.17487/RFC6020，2010年10月<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6241]Enns，R.，Ed.，Bjorklund，M.，Ed.，Schoenwaeld，J.，Ed.，和A.Bierman，Ed.，“网络配置协议（NETCONF）”，RFC 6241，DOI 10.17487/RFC6241，2011年6月<http://www.rfc-editor.org/info/rfc6241>.
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，DOI 10.17487/RFC6513，2012年2月<http://www.rfc-editor.org/info/rfc6513>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, DOI 10.17487/RFC6536, March 2012, <http://www.rfc-editor.org/info/rfc6536>.
[RFC6536]Bierman，A.和M.Bjorklund，“网络配置协议（NETCONF）访问控制模型”，RFC 6536，DOI 10.17487/RFC6536，2012年3月<http://www.rfc-editor.org/info/rfc6536>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <http://www.rfc-editor.org/info/rfc7950>.
[RFC7950]Bjorklund，M.，Ed.“YANG 1.1数据建模语言”，RFC 7950，DOI 10.17487/RFC7950，2016年8月<http://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <http://www.rfc-editor.org/info/rfc8040>.
[RFC8040]Bierman，A.，Bjorklund，M.，和K.Watsen，“RESTCONF协议”，RFC 8040，DOI 10.17487/RFC8040，2017年1月<http://www.rfc-editor.org/info/rfc8040>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, DOI 10.17487/RFC4110, July 2005, <http://www.rfc-editor.org/info/rfc4110>.
[RFC4110]Callon，R.和M.Suzuki，“第3层提供商提供的虚拟专用网络（PPVPN）框架”，RFC 4110，DOI 10.17487/RFC4110，2005年7月<http://www.rfc-editor.org/info/rfc4110>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，DOI 10.17487/RFC4760，2007年1月<http://www.rfc-editor.org/info/rfc4760>.
Acknowledgements
致谢
Thanks to Qin Wu, Maxim Klyus, Luis Miguel Contreras, Gregory Mirsky, Zitao Wang, Jing Zhao, Kireeti Kompella, Eric Rosen, Aijun Wang, Michael Scharf, Xufeng Liu, David Ball, Lucy Yong, Jean-Philippe Landry, and Andrew Leu for their contributions to this document.
感谢秦武、马克西姆·克鲁斯、路易斯·米格尔·孔特雷拉斯、格雷戈里·米尔斯基、王子涛、赵静、科佩拉、埃里克·罗森、王爱军、迈克尔·沙尔夫、刘旭峰、大卫·鲍尔、杨露西、让·菲利普·兰德里和安德鲁·勒乌对本文件的贡献。
Contributors
贡献者
The authors would like to thank Rob Shakir for his major contributions to the initial modeling and use cases.
作者要感谢Rob Shakir对初始建模和用例做出的重大贡献。
Authors' Addresses
作者地址
Stephane Litkowski Orange Business Services
Stephane Litkowski橙色商务服务
Email: stephane.litkowski@orange.com
Email: stephane.litkowski@orange.com
Luis Tomotaki Verizon
路易斯·托莫塔基·威瑞森
Email: luis.tomotaki@verizon.com
Email: luis.tomotaki@verizon.com
Kenichi Ogaki KDDI Corporation
大垣健一株式会社
Email: ke-oogaki@kddi.com
Email: ke-oogaki@kddi.com