CPP：IP 连接配置文件

RFC7297：IP Connectivity Provisioning Profile (CPP)，July 2014

梗概

本文档描述了连接配置文件 (Connectivity Provisioning Profile，CPP) 并提出了一个 CPP 模板来捕获要在服务交付环境（例如，IP 语音或 IP 电视）内满足的 IP/MPLS 连接要求。CPP 定义了底层传输网络支持的 IP 传输参数集以及可达性范围和带宽/容量需求。适当的性能指标，例如单向延迟或单向延迟变化，用于表征 IP 传输服务。全局和受限可达性范围都可以在 CPP 中捕获。

这种通用的 CPP 模板旨在：

(1) 促进服务协商和激活过程的自动化，从而加速服务提供，

(2) 设置流量工程功能和服务管理功能的（流量）目标，以及

(3) 改进服务和具有基于协商/提供的 CPP 的“决策”能力的网络管理系统。

本备忘录的状态

本文档不是 Internet Standards Track 规范；它是为了信息目的而发布的。

这是对 RFC 系列的贡献，独立于任何其他 RFC 流。RFC 编辑器已自行决定发布此文档，并且不对其实施或部署的价值作出任何声明。由 RFC 编辑批准发布的文件不适合任何级别的 Internet 标准；请参阅 RFC 5741 的第 2 节。

有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc7297。

版权声明

版权所有 (c) 2014 IETF Trust 和确定为文档作者的人员。版权所有。

本文档受 BCP 78 和 IETF Trust 的与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。

1、 介绍

本文档描述了连接配置文件 (CPP) 并提出了一个 CPP 模板来捕获要在服务交付环境中满足的 IP/MPLS 连接要求（例如，IP 语音、IP TV 和 VPN 服务）。

在本文档中，IP连接服务是一种以(Source Nets, Destination Nets, Guarantees, Scope)元组为特征的IP传输能力，其中“Source Nets”是一组单播IP地址，“Destination Nets”是一组IP地址单播和/或组播地址，“Guarantees”反映了将流量正确转发到所述“Destination”的保证（例如，以服务质量 (Quality Of Service，QoS)、性能和可用性表示）。最后，“Scope”表示需要提供所述保证的（网络）边界（例如，提供商边缘（PE）路由器或客户节点之间）。

1.1、 连接供应接口 (CPI)

图 1 显示了 CPP 涵盖的各种连接供应接口：客户网络 CPI、服务网络 CPI 和网络网络 CPI。其参数通过通过服务网络 CPI 交换的 CPP 捕获的服务和应用程序可以由操作底层网络的同一管理实体或由另一个实体（例如，内容提供商）提供。

图 1：连接配置接口

图 1 中描述的界面可以概括为图 2 所示。

图 2 中所示的客户可能是另一个网络提供商（例如，IP 传输提供商）、需要调用网络提供商提供的资源的服务提供商（例如，IP 电话服务提供商），或者想要 通过订阅网络提供商提供的 VPN 服务，将其各个站点互连。提议的 CPP 可用于公开、捕获和促进这些不同实体之间服务参数的协商，从而提供用于描述可用连接服务的通用模板。

图 2：CPP：通用连接配置接口

在本文档的其余部分，“客户”用作通用术语，表示订阅网络提供商提供的连接服务的业务实体（参见图 2）。

1.2、 基本原理

知识产权服务的设计和运营程序变得越来越多样化和复杂。协商服务参数然后继续进行相应的资源分配所花费的时间因此可以以天计，甚至以周计。然而，经验表明，通常发生在客户和网络提供商之间的双边讨论从不依赖于某种标准清单，客户将被邀请勾选适用于其环境的所有参数。然后将根据可用资源、客户的期望、提供商的网络规划策略等与网络提供商协商这些参数。

因此，在服务（包括第三方应用程序）和网络层之间定义清晰的接口将有助于上述讨论，从而通过优化网络基础设施的设计来改进整体服务交付过程。实际上，CPP 接口旨在以与技术无关的方式公开和表征在调用由网络提供商在一组客户节点之间运营的网络的 IP 传输能力时要满足的 IP 传输要求。（例如，多媒体网关[RFC2805] 的第 11.2.7 节，会话边界控制器 [RFC5853] 等）。

这些要求包括：可达性范围（例如，有限范围、互联网范围）、方向、带宽要求、QoS 参数（例如，单向延迟 [RFC2679]、丢失 [RFC2680] 或单向延迟变化 [RFC3393]） 、保护和高可用性指南（例如，在不到 50 毫秒、100 毫秒或 1 秒内恢复）。

然后将这些要求转化为与 IP/MPLS 相关的技术条款（例如，需要恢复手段、定义服务等级、需要控制平面保护等）。在稍后的阶段，这些不同的条款将通过激活适当的网络功能和特定于技术的操作（例如，多协议标签交换流量工程（Multiprotocol Label Switching Traffic Engineering，MPLS-TE，[RFC3346]）、资源预留协议（Resource Reservation Protocol，RSVP，[RFC2205]）来解决)、开放最短路径优先 (Open Shortest Path First，OSPF)、中间系统到中间系统 (Intermediate System to Intermediate System，IS-IS) 等），通过 CPP 派生的配置信息。

出于流量一致性的目的，CPP 还包括参与节点在必须根据所述 CPP 定义的特定服务处理流量时遵循的流识别和分类规则。

CPP 模板旨在捕捉连接需求并以标准化方式表示和评估这些需求。特定于服务和客户的 IP 配置规则可能会导致需要在网络中（预）设计的 IP 传输类的数量急剧增加。因此，为了性能和可扩展性，应避免将每个 CPP 实例化为不同的服务类别。

因此，应推荐与应用程序无关的 IP 配置实践，因为 CPP 中捕获的要求可用于确定将使用哪种网络服务类别来满足这些要求/保证。从这个角度来看，CPP 概念旨在设计数量有限的通用类，以便通过捕获服务、应用程序和客户的连接要求，可以轻松地将各个 CPP 文档映射到这些类。

CPP 还可用作网络提供商的网络尺寸和规划团队的指南，以确保已提供适当的资源（例如，网卡、路由器、链路容量等）。否则，（底层）传输网络将无法满足所有 CPP 请求中表达的目标。

这样一个通用的 CPP 模板：

** 促进服务协商和激活程序的自动化，从而缩短服务交付时间；

** 可以帮助设置流量工程功能和服务管理功能目标，例如作为特定时间段内要处理的CPP模板数量的函数；和

** 通过添加基于协商/提供的 CPP 的“决策”功能来改进服务和网络管理系统。

此外，此 CPP 抽象明确区分了连接供应要求和需要由参与节点应用并旨在满足此类要求的相关技术特定规则。

CPP 定义了由底层传输网络提供的一组 IP/MPLS 传输保证以及可达性范围和容量需求。适当的性能指标，例如单向延迟或单向延迟变化，用于表征 IP 传输服务。CPP 中还包括与可用性和弹性相关的保证。

CPP 可用于集成业务环境（其中服务和网络基础设施由同一管理实体管理）或其他业务环境（其中一个管理实体管理服务而另一个管理网络基础设施）。在以下部分中，不对业务环境（集成与否）做出任何假设。

可以通过调整属于不同维度的各种参数（例如，转发、路由、传入流量的处理、流量分类等）来实施网络层的服务差异化。本文档不对如何在网络基础设施中实现网络服务做出任何假设。

激活单播或组播功能以提供连接服务可以由客户在 CPP 中明确请求，也可以是网络提供商基于对客户连接供应需求的分析做出的工程决策。

CPP 使用的示例包括由基于应用程序的网络操作 (Application-Based Network Operations，ABNO) 框架 [NET-OPS] 引入的北向接口以及 [RFC7149] 中定义的用于公开网络服务及其特征的技术。

1.3、 参考架构

客户节点属于一个客户（包括企业客户）或一个服务基础设施（见图 1）。在某些情况下，客户节点可以由网络提供商提供和管理。这些客户节点之间的连接反映了由于一组 IP 资源的分配而实现的 IP 传输能力。IP 传输能力被高层服务（例如传输层和应用层服务）视为黑匣子。将（通过专用方式）向客户节点传达适当的通知和报告，以评估经验丰富的 IP 传输服务是否符合与相应 CPP 协商的内容。这些通知还可用于评估在网络基础设施中实施的各种策略的效率，以适应 CPP 中详述的要求。

CPP 参考架构如图 3、4 和 5 所示。

客户基础设施可以通过由一个或多个网络提供商管理的网络基础设施进行连接。

图 3：参考架构：由同一网络提供商使用不同的互连节点提供的连接服务

图 4：参考架构：由同一网络提供商使用单个互连节点提供的连接服务

图 5：参考架构：不同网络提供商提供的连接服务

2、 本文件的范围

本文件详细介绍了 CPP 的条款。本文档不讨论可用于协商和执行给定 CPP 的候选协议（例如 [CPNP]）。

除 CPP 条款外，客户与提供商之间的协议中还可能包含其他条款（例如，联系点、升级程序、事件管理、计费等）。详细说明所有这些附加条款超出了本文档的范围。

提供了如何将 CPP 条款转化为具体政策的示例，以供说明之用。提供满足 CPP 中详述目标的技术手段的详尽清单超出了本文件的范围。

CPP 主要针对 IP 连接服务而设计。然而，它可以用于其他非 IP 传输方案。评估 CPP 对这些非 IP 方案的适用性超出了本文件的范围。

本文档涵盖单播和组播连接服务。任意源组播（Any-Source Multicast，ASM，[RFC1112]）和源特定组播（Source-Specific Multicast，SSM，[RFC4607]）模式都可以在 CPP 中捕获。

3、 连接配置文件 (CPP)

CPP 可被视为与 IP 传输服务相关的连接供应要求清单。CPP 条款在以下小节中详细说明。第 4 节提供了 CPP 模板。

3.1、 客户节点图

CPP 必须包括要连接到底层 IP 传输网络的客户节点（例如，客户边缘 (Customer Edges，CE)）的列表。

这些节点应该被明确标识（例如，使用唯一的 Service_identifier、媒介接入控制 (Media Access Control，MAC) 地址等）。对于每个客户节点，应标识边界链路或属于连接客户节点的域的节点。

该子句可以指定客户节点的地理位置信息。

根据客户节点的位置，应该采取适当的操作来检索相应的边界链路或“提供商节点”（例如，PE）。此操作可以是手动的或自动的。

“服务站点”将位于给定的客户节点后面。可以在 CPP 中捕获站点标识符以提供托管 VPN 服务 [RFC4026]，例如 Site_identifier。

一个客户节点可以连接到多个提供商节点。多个客户节点可以连接到同一个提供商节点，如图 4 所示。

3.2、 范围

范围条款从传入和传出流量的角度指定每个涉及的客户节点的可达性，从而产生特定的流量方向性考虑。它被定义为单向参数。这两个方向都应在 CPP 中进行描述。

可达性范围指定可从给定客户站点（由一组源前缀标识）到达的一组目标前缀。全局和受限可达性范围都可以在 CPP 中捕获。全局可达性范围意味着客户站点可以到达 Internet 中的任何目的地，并且可以从任何远程主机到达。受限可达性范围意味着不允许全局可达性；从客户站点只能到达一组目的地，和/或只有一组源可以到达客户站点。CPP 中指定了传入和传出可达性范围。

可以指定 IPv4 和 IPv6 可达性范围。

可达性范围条款可以包括组播和/或单播地址。对于SSM，除了目的组播地址外，还可以指定一组单播源地址。

范围子句还可用于界定拓扑（或地理）网络部分，超出该部分性能和可用性保证不适用。范围可以由一组“入口”点和“出口”点来定义。可以考虑几种类型，例如：

(1) “1:1”管道模型。只允许点对点通信。

(2) “1:N”软管道型号。只允许从一个站点到一组目的地的通信。

(3) “1:any”未指定的软管道型号。允许所有出站通信。

入口和出口点可以是客户节点/提供商节点或外部节点，前提是这些节点被明确标识（例如，IPv6 前缀）或一组 IP 目的地。

3.3、 服务质量保证

QoS 保证表示一组 IP 传输性能指标，这些指标表征从（一组）“客户节点”发出或转发到（一组）“客户节点”的流所经历的 IP 传输处理的质量（当穿过 IP 传输基础设施时） .

IP 性能指标可以表示为定性或定量参数（不能在同一个 CPP 中指定定量和定性保证）。定量保证可以指定为平均值、最大界限或测量方法中应指明的测量间隔的百分位数。

已经定义了几个性能指标，例如：

** 流量丢失 [RFC2680]

** 单向延迟 [RFC2679]

** 单向延迟变化 [RFC3393]

这些参数可能特定于给定的路径或给定的范围（例如，在两个客户节点之间）。CPP 中指示的 IP 性能度量值应反映一组客户节点之间或一个客户节点与一组提供商节点之间的度量。

只能为配置文件内的流量（即达到一定的流量速率）指定定量保证。CPP 可以包括吞吐量保证；在指定时，这些保证等同于数量或质量损失保证。

当使用定性指标时，可以使用 Meta-QoS-Class 概念 [RFC5160]。

3.4、 可用性

本条款规定了商定的 IP 性能保证适用的时间百分比。该子句可以表示为最大值或平均值。子句值的确切含义是在 CPP 协商过程中定义的。

保证涵盖 QoS 恶化（即 IP 传输服务可用，但低于商定的性能界限）、物理故障或服务不可用。为了满足可用性保证，可能会在客户和网络提供商之间的边界处实施多种工程实践，例如多宿主设计。

提供以下机制作为示例，以表明可以选择不同的技术选项来满足服务可用性目标：

** 当内部网关协议 (Interior Gateway Protocol，IGP) 实例在“客户节点”和“提供商节点”之间运行时，激活专用协议，例如双向转发检测 (Bidirectional Forwarding Detection，BFD，[RFC5881][RFC5883])，以控制 IGP可用性并确保亚秒级 IGP 邻接故障检测。

** 使用标签交换路径 Ping (Label Switched Path Ping，LSP Ping) 能力检测 LSP 可用性（检查 LSP 是否就位）[RFC4379][RFC6424][RFC6425][RFC6426][RFC6829]。

** 当 MPLS 网络连接客户节点 [RFC4090] 时，预安装备份 LSP 用于快速重新路由。

** 启用虚拟路由器冗余协议 (Virtual Router Redundancy Protocol，VRRP, [RFC5798])。

** 启用 IP 快速重新路由功能（例如，[RFC5286] 或 [RFC6981]）。

3.5、 容量

本节描述了由底层 IP 传输网络提供的所需容量。此容量受定义的“范围”（参见第 3.2 节）和 IP 传输性能保证（参见第 3.3 和 3.4 节）的约束。

容量可以针对两个业务方向（即传入和传出）和每个边界链路表示。能力条款定义了数量保证的应用限制。

由管理 IP 传输网络的管理实体决定其网络 [RFC5136] 的适当尺寸以满足所有协商的 CPP 中表达的容量要求。

3.6、 一致性流量

当容量信息（参见第 3.5 节）包含在 CPP 中时，还需要在 CPP 中表达对超出规范的流量处理的要求。

可以应用整形/管制过滤器以评估流量是在容量配置文件内还是在配置文件外。超出规范的流量可能会被丢弃或分配另一个类别（例如，使用低工作量每域行为（Lower Effort Per-Domain Behavior，LE PDB）[RFC3662]）。

分组 MTU 条件也可以在 CPP 中指示。

3.7、 整体流量保障

当未指定容量（第 3.5 节）和一致性流量（第 3.6 节）条款时，定义了总体流量保证。或者，如果它们确实被指定，那么超出配置文件的流量会被分配另一类服务，但不会被丢弃。这种保证只能是定性延迟和/或定性损失或吞吐量保证。

如果未指定总体流量保证，则暗示了尽力而为转发。

3.8、 流量隔离

本节指出在穿越 IP 传输网络时，是否应该隔离由“客户节点”发出或发往“客户节点”的流量。本条款还可用于指定附加的安全保护要求（包括隐私保护要求）。

然后，该条款可以转换为 VPN 策略提供信息，例如与使用 IPsec、BGP/MPLS VPN 设施 [RFC4364] 或其组合激活专用隧道有关的信息。此类功能的激活应与已协商的可用性和性能保证一致。

3.9、 流量识别

为了识别需要在给定 CPP 的环境中处理的流，流标识符应在 CPP 中指示。流标识符用于流量分类目的。[RFC2475]中定义了一个包分类器的例子。

流标识符可以由（但不限于）以下参数组成：

** 源IP地址，

** 源端口号，

** 目标 IP 地址，

** 目标端口号，

** 服务类型 (Type of Service，ToS) 或差异化服务代码点 (Differentiated Services Code Point，DSCP) 字段，

** 尾端隧道端点，或

** 任何组合。

可以对弹性和非弹性流量实施不同的处理（例如，参见 [RFC5160] 中定义的“流量约束”条款）。

流分类规则可能特定于给定的链接，也可能适用于一组或所有边界链接。这应该在 CPP 中清楚地体现出来。

CPP 中可能会指明一些做法，例如 DSCP 重新标记。重新标记操作由干预以提供连接服务的底层节点负责。可以对从客户节点接收或发往客户节点的传出和传入流量强制执行重新标记。这些重新标记操作不得改变特定于服务的标记完整性（例如，VPN 服务）。

该条款可以指定在出口节点对从客户节点接收的数据包实施的策略（例如，DSCP 重新标记）。如果未指定此类策略，则网络提供商对离开其管理域的数据包强制执行其本地策略（例如，清除 DSCP 标记）。

3.10、 路由和转发

该条款用于指定外包路由操作，例如安装专用路由以将流量传送到其（服务）目的地。可以出于流量工程或弹性目的计算、选择和安装这些专用路由。对于流量工程，这些路径可用于智能地将流量从可能遭受拥塞或避免穿越竞争对手网络的某些节点/链路转移。对于弹性，备份路径通常是预先安装的，以便绕过受保护的节点/链接。

本节还用于指定必须在转发路径中调用的中间功能（例如，将流量重定向到防火墙、调用拓扑隐藏功能等）或指定地理路由限制。

还可以考虑建立逻辑路由拓扑 [RFC4915] [RFC5120] 的要求，例如，以促进在 CPP 中定义的流量转发中涉及的节点的管理。

这种做法应在 CPP 中指明；否则，路径计算将留给底层 IP 路由功能。转发行为（例如，每域行为（Per-Domain Behavior，PDB）[RFC3086]）也可以在 CPP 中指定，但仍然是可选的。如果指出，应仔细确保与 CPP 中定义的 IP 性能界限的一致性。

出于说明目的，路由策略将避免基于 IP 语音 (Voice over IP，VoIP) 部署的卫星链路，因为这可能会降低所提供的服务。

3.11、 激活方式

本节指出了为激活对 IP 连接服务的访问而需要采取的行动。

这些操作的示例包括激活 IGP 实例、建立 BGP [RFC4271] 或多协议 BGP (Multiprotocol BGP，MP-BGP) 会话 [RFC4760]、协议无关组播 (Protocol Independent Multicast，PIM, [RFC4601]) 等。

3.12、 调用方式

定义了两种类型：

隐式：该子句表示不需要调用连接服务的显式方法。对连接服务的访问主要取决于请求的网络容量。

显式：该条款表明需要显式方式来访问连接服务。此类手段的示例包括使用 RSVP [RFC2205]、RSVP-TE [RFC3209]、互联网组管理协议（Internet Group Management Protocol，IGMP，[RFC3376]）或组播侦听器发现（Multicast Listener Discovery，MLD，[RFC3810]）。必须执行适当的准入控制程序 [RFC6601]，例如，检查实际使用的容量是否不高于商定的阈值。

3.13、 通知

出于运营目的（例如，监督）和服务履行需求，需要将可能影响服务交付的关键事件通知管理平台。

通知程序应在 CPP 中指明。此过程可以指定要发送的信息类型、间隔、数据模型等。

可以使用简单网络管理协议（Simple Network Management Protocol，SNMP，[RFC3416]）、系统日志通知[RFC5424]、连接提供协商协议（Connectivity Provisioning Negotiation Protocol，CPNP）信号[CPNP]、网络配置协议（Network Configuration Protocol，NETCONF）事件通知[RFC5277]向管理平台发送通知]，或一个电话！

4、 CPP 模板

图 6 提供了 CPP 模板的 Routing Backus-Naur Form (RBNF, [RFC5511]) 格式。

CPP 文档包括几个连接供应组件；每一个都被构建为一个 CPP。CPP 可能包括额外的可选信息元素，例如用于服务保证目的的度量、激活计划等。

<CONNECTIVITY_PROVISIONING_DOCUMENT> ::= <Connectivity Provisioning Component> ...
<Connectivity Provisioning Component>::= <CONNECTIVITY_PROVISIONING_PROFILE> ...
<CONNECTIVITY_PROVISIONING_PROFILE>  ::= <Customer Nodes Map>
                                         <Scope>
                                         <QoS Guarantees>
                                         <Availability>
                                         <Capacity>
                                         <Traffic Isolation>
                                         <Conformance Traffic>
                                         <Flow Identification>
                                         <Overall Traffic Guarantees>
                                         <Routing and Forwarding>
                                         <Activation Means>
                                         <Invocation Means>
                                         <Notifications>
                                         <Optional Information Element> ...
                                         <Customer Nodes Map> ::= <Customer Node> ...
                                         <Customer Node> ::= <IDENTIFIER>
                                         <LINK_IDENTIFIER>
                                         <LOCALIZATION>

                                                                       图 6：CPP 模板

这些条款的描述在第 3 节中提供。

CPP 还可能包括客户的管理信息，例如姓名和其他联系方式。客户信息的 RBNF 格式示例如图 7 所示。

<Customer Description> ::= <NAME> <Contact Information>
<Contact Information>  ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>] [<TELEPHONE_NUMBER> ...]

                                                   图 7：客户描述条款

CPP 也可能包括网络提供商的管理信息（姓名、自治系统编号和其他联系方式）。提供者信息的 RBNF 格式示例如图 8 所示。

<Provider Description> ::= <NAME><Contact Information>[<AS_NUMBER>]
<Contact Information>  ::= <EMAIL_ADDRESS> [<POSTAL_ADDRESS>] [<TELEPHONE_NUMBER> ...]

                                                   图 8：提供者描述条款

5、 安全考虑

本文档不定义架构或指定协议。然而，需要调查提供有关客户身份的保证及其通过 CPP 向网络提供商公开连接要求的能力的方法。同样，应仔细研究为网络提供商的身份和公开其能力的能力提供保证的方法，更不用说通过 CPP 捕获客户的要求了。

应保护 CPP 文件免遭非法修改（例如，修改、撤回）；应启用授权手段。这些方法是特定于部署的。

网络提供商必须采取措施保护 CPP 文档 [RFC6462] 中捕获的隐私相关信息。特别是，未经客户同意，不得将这些信息透露给外部各方。网络提供商应执行政策，使客户指纹识别更难实现。有关隐私的更多讨论，请参阅 [RFC6462] 和 [RFC6973]。

6、 致谢

本文档中的某些项目是与 E. Mykoniati 和 D. Griffin 多次讨论的结果。特别感谢他们。

非常感谢 P. Georgatsos 的讨论和对本文档的详细审查。

感谢 S. Shah、G. Huston、D. King 和 S. Bryant 审阅文档并提供有用的意见。

7、 参考资料

[CPNP] Boucadair, M., Jacquenet, C., and D. Zhang, "Connectivity Provisioning Negotiation Protocol (CPNP)", Work in Progress, June 2014.
[NET-OPS] King, D. and A. Farrel, "A PCE-based Architecture for Application-based Network Operations", Work in Progress, February 2014.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2805] Greene, N., Ramalho, M., and B. Rosen, "Media Gateway Control Protocol Architecture and Requirements", RFC 2805, April 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, August 2002.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, February 2008.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, March 2008.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, June 2010.
[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels", RFC 6424, November 2011.
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6462] Cooper, A., "Report from the Internet Privacy Workshop", RFC 6462, January 2012.
[RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", RFC 6601, April 2012.
[RFC6829] Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6", RFC 6829, January 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013.
[RFC6981] Bryant, S., Previdi, S., and M. Shand, "A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981, August 2013.
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, March 2014.