draft-nsdt-teas-ietf-network-slice-definition-01.txt | draft-nsdt-teas-ietf-network-slice-definition-02.txt | |||
---|---|---|---|---|
teas R. Rokui | teas R. Rokui | |||
Internet-Draft Nokia | Internet-Draft Nokia | |||
Intended status: Informational S. Homma | Intended status: Informational S. Homma | |||
Expires: May 6, 2021 NTT | Expires: June 14, 2021 NTT | |||
K. Makhijani | K. Makhijani | |||
Futurewei | Futurewei | |||
LM. Contreras | LM. Contreras | |||
Telefonica | Telefonica | |||
J. Tantsura | J. Tantsura | |||
Apstra, Inc. | Apstra, Inc. | |||
November 2, 2020 | December 11, 2020 | |||
Definition of IETF Network Slices | Definition of IETF Network Slices | |||
draft-nsdt-teas-ietf-network-slice-definition-01 | draft-nsdt-teas-ietf-network-slice-definition-02 | |||
Abstract | Abstract | |||
This document provides a definition of the term "IETF Network Slice" | This document provides a definition of the term "IETF Network Slice" | |||
for use within the IETF and specifically as a reference for other | for use within the IETF and specifically as a reference for other | |||
IETF documents that describe or use aspects of network slices. | IETF documents that describe or use aspects of network slices. | |||
The document also describes the characteristics of an IETF network | The document also describes the characteristics of an IETF network | |||
slice, related terms and their meanings, and explains how IETF | slice, related terms and their meanings, and explains how IETF | |||
network slices can be used in combination with end-to-end network | network slices can be used in combination with end-to-end network | |||
skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 44 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 6, 2021. | This Internet-Draft will expire on June 14, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 | ||||
3. Definition and Scope of IETF Network Slice . . . . . . . . . 4 | 3. Definition and Scope of IETF Network Slice . . . . . . . . . 4 | |||
4. IETF Network Slice System Characteristics . . . . . . . . . . 5 | 4. IETF Network Slice System Characteristics . . . . . . . . . . 4 | |||
4.1. Objectives for IETF Network Slices . . . . . . . . . . . 5 | 4.1. Objectives for IETF Network Slices . . . . . . . . . . . 5 | |||
4.1.1. Service Level Objectives . . . . . . . . . . . . . . 5 | 4.1.1. Service Level Objectives . . . . . . . . . . . . . . 5 | |||
4.1.2. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 6 | 4.1.2. Minimal Set of SLOs . . . . . . . . . . . . . . . . . 5 | |||
4.1.3. Other Objectives . . . . . . . . . . . . . . . . . . 7 | 4.1.3. Other Objectives . . . . . . . . . . . . . . . . . . 7 | |||
4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 7 | 4.2. IETF Network Slice Endpoints . . . . . . . . . . . . . . 7 | |||
4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 9 | 4.2.1. IETF Network Slice Connectivity Types . . . . . . . . 9 | |||
4.3. IETF Network Slice Composition . . . . . . . . . . . . . 9 | 4.3. IETF Network Slice Composition . . . . . . . . . . . . . 9 | |||
5. IETF Network Slice Structure . . . . . . . . . . . . . . . . 10 | 5. IETF Network Slice Structure . . . . . . . . . . . . . . . . 10 | |||
6. IETF Network Slice Stakeholders . . . . . . . . . . . . . . . 11 | 6. IETF Network Slice Stakeholders . . . . . . . . . . . . . . . 11 | |||
7. IETF Network Slice Controller Interfaces . . . . . . . . . . 12 | 7. IETF Network Slice Controller Interfaces . . . . . . . . . . 12 | |||
8. Realizing IETF Network Slice . . . . . . . . . . . . . . . . 12 | 8. Realizing IETF Network Slice . . . . . . . . . . . . . . . . 12 | |||
9. Isolation in IETF Network Slices . . . . . . . . . . . . . . 13 | 9. Isolation in IETF Network Slices . . . . . . . . . . . . . . 13 | |||
9.1. Isolation as a Service Requirement . . . . . . . . . . . 13 | 9.1. Isolation as a Service Requirement . . . . . . . . . . . 13 | |||
9.2. Isolation in IETF Network Slice Realization . . . . . . . 14 | 9.2. Isolation in IETF Network Slice Realization . . . . . . . 13 | |||
9.3. Relationship with Isolation in 5G Network Slice . . . . . 14 | ||||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 | 12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
13. Informative References . . . . . . . . . . . . . . . . . . . 15 | 13. Informative References . . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
1. Introduction | 1. Introduction | |||
A number of use cases benefit from network connections that along | A number of use cases benefit from network connections that along | |||
with the connectivity provide assurance of meeting a specific set of | with the connectivity provide assurance of meeting a specific set of | |||
objectives wrt network resources use. In this document, as detailed | objectives wrt network resources use. In this document, as detailed | |||
in the subsequent sections, we refer to this connectivity and | in the subsequent sections, we refer to this connectivity and | |||
skipping to change at page 3, line 18 ¶ | skipping to change at page 3, line 17 ¶ | |||
o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) | o 5G services (e.g. eMBB, URLLC, mMTC)(See [TS.23.501-3GPP]) | |||
o Network wholesale services | o Network wholesale services | |||
o Network infrastructure sharing among operators | o Network infrastructure sharing among operators | |||
o NFV connectivity and Data Center Interconnect | o NFV connectivity and Data Center Interconnect | |||
The use cases are further described in [I-D.nsdt-teas-ns-framework]. | The use cases are further described in [I-D.nsdt-teas-ns-framework]. | |||
This document defines the concept of IETF Network Slices that provide | This document defines the concept of IETF network slices that provide | |||
connectivity coupled with a set of specific commitments of network | connectivity coupled with a set of specific commitments of network | |||
resources between a number of endpoints over a shared network | resources between a number of endpoints over a shared network | |||
infrastructure. Since the term network slice is rather generic, the | infrastructure. Since the term network slice is rather generic, the | |||
qualifying term 'IETF' is used in this document to limit the scope of | qualifying term 'IETF' is used in this document to limit the scope of | |||
network slice to network technologies described and standardized by | network slice to network technologies described and standardized by | |||
the IETF. | the IETF. | |||
1.1. Rationale | IETF network slices are created and managed within the scope of one | |||
IETF Network Slices are created and managed within the scope of one | ||||
or more network technologies (e.g., IP, MPLS, optical). They are | or more network technologies (e.g., IP, MPLS, optical). They are | |||
intended to enable a diverse set of applications that have different | intended to enable a diverse set of applications that have different | |||
requirements to coexist on the same network infrastructure. | requirements to coexist on the same network infrastructure. A | |||
request for an IETF network slice is technology-agnostic so as to | ||||
An IETF Network Slice is a well-defined structure of connectivity | allow a consumer to describe their network connectivity objectives in | |||
requirements and associated network behaviors. IETF Network Slices | a common format, independent of the underlying technologies used. | |||
are defined such that they are independent of the underlying | ||||
infrastructure connectivity and technologies used. This is to allow | ||||
an IETF Network Slice consumer to describe their network connectivity | ||||
and relevant objectives in a common format, independent of the | ||||
underlying technologies used. | ||||
IETF Network Slices may be combined hierarchically, so that a network | ||||
slice may itself be sliced. They may also be combined sequentially | ||||
so that various different networks can each be sliced and the network | ||||
slices placed into a sequence to provide an end-to-end service. This | ||||
form of sequential combination is utilized in some services such as | ||||
in 3GPP's 5G network [TS.23.501-3GPP]. | ||||
2. Terms and Abbreviations | 2. Terms and Abbreviations | |||
The terms and abbreviations used in this document are listed below. | The terms and abbreviations used in this document are listed below. | |||
o NS: Network Slice | o NS: Network Slice | |||
o NSC: Network Slice Controller | o NSC: Network Slice Controller | |||
o NBI: NorthBound Interface | o NBI: NorthBound Interface | |||
skipping to change at page 4, line 22 ¶ | skipping to change at page 4, line 4 ¶ | |||
o NBI: NorthBound Interface | o NBI: NorthBound Interface | |||
o SBI: SouthBound Interface | o SBI: SouthBound Interface | |||
o SLI: Service Level Indicator | o SLI: Service Level Indicator | |||
o SLO: Service Level Objective | o SLO: Service Level Objective | |||
o SLA: Service Level Agreement | o SLA: Service Level Agreement | |||
The above terminology is defined in greater details in the remainder | The above terminology is defined in greater details in the remainder | |||
of this document. | of this document. | |||
3. Definition and Scope of IETF Network Slice | 3. Definition and Scope of IETF Network Slice | |||
The definition of a network slice in IETF context is as follows: | The definition of a network slice in IETF context is as follows: | |||
An IETF Network Slice is a logical network topology connecting a | An IETF network slice is a logical network topology connecting a | |||
number of endpoints with a set of shared or dedicated network | number of endpoints using a set of shared or dedicated network | |||
resources, that are used to satisfy specific Service Level Objectives | resources that are used to satisfy specific Service Level Objectives | |||
(SLOs). | (SLOs). | |||
IETF Network Slice specification is technology-agnostic, and the | An IETF network slice combines the connectivity resource requirements | |||
means for IETF network slice realization can be chosen depending on | and associated network behaviors such as bandwidth, latency, jitter, | |||
several factors such as: service requirements, specifications or | and network functions with other resource behaviors such as compute | |||
capabilities of underlying infrastructure. The structure and | and storage availability. IETF network slices are independent of the | |||
different characteristics of IETF Network Slices are described in the | underlying infrastructure connectivity and technologies used. This | |||
following sections. | is to allow an IETF network slice consumer to describe their network | |||
connectivity and relevant objectives in a common format, independent | ||||
of the underlying technologies used. | ||||
IETF network slices may be combined hierarchically, so that a network | ||||
slice may itself be sliced. They may also be combined sequentially | ||||
so that various different networks can each be sliced and the network | ||||
slices placed into a sequence to provide an end-to-end service. This | ||||
form of sequential combination is utilized in some services such as | ||||
in 3GPP's 5G network [TS.23.501-3GPP]. | ||||
An IETF network slice is technology-agnostic, and the means for IETF | ||||
network slice realization can be chosen depending on several factors | ||||
such as: service requirements, specifications or capabilities of | ||||
underlying infrastructure. The structure and different | ||||
characteristics of IETF network slices are described in the following | ||||
sections. | ||||
Term "Slice" refers to a set of characteristics and behaviours that | Term "Slice" refers to a set of characteristics and behaviours that | |||
separate one type of user-traffic from another. IETF Network Slice | separate one type of user-traffic from another. IETF network slice | |||
assumes that an underlying network is capable of changing the | assumes that an underlying network is capable of changing the | |||
configurations of the network devices on demand, through in-band | configurations of the network devices on demand, through in-band | |||
signaling or via controller(s) and fulfilling all or some of SLOs to | signaling or via controller(s) and fulfilling all or some of SLOs to | |||
all of the traffic in the slice or to specific flows. | all of the traffic in the slice or to specific flows. | |||
4. IETF Network Slice System Characteristics | 4. IETF Network Slice System Characteristics | |||
The following subsections describe the characteristics of IETF | The following subsections describe the characteristics of IETF | |||
network slices. | network slices. | |||
4.1. Objectives for IETF Network Slices | 4.1. Objectives for IETF Network Slices | |||
An IETF Network Slice is defined in terms of several quantifiable | An IETF network slice is defined in terms of several quantifiable | |||
characteristics or service level objectives (SLOs). SLOs along with | characteristics or service level objectives (SLOs). SLOs along with | |||
terms Service Level Indicator (SLI) and Service Level Agreement (SLA) | terms Service Level Indicator (SLI) and Service Level Agreement (SLA) | |||
are used to define the performance of a service at different levels. | are used to define the performance of a service at different levels. | |||
A Service Level Indicator (SLI) is a quantifiable measure of an | A Service Level Indicator (SLI) is a quantifiable measure of an | |||
aspect of the performance of a network. For example, it may be a | aspect of the performance of a network. For example, it may be a | |||
measure of throughput in bits per second, or it may be a measure of | measure of throughput in bits per second, or it may be a measure of | |||
latency in milliseconds. | latency in milliseconds. | |||
A Service Level Objective (SLO) is a target value or range for the | A Service Level Objective (SLO) is a target value or range for the | |||
measurements returned by observation of an SLI. For example, an SLO | measurements returned by observation of an SLI. For example, an SLO | |||
may be expressed as "SLI <= target", or "lower bound <= SLI <= upper | may be expressed as "SLI <= target", or "lower bound <= SLI <= upper | |||
bound". A network slice is expressed in terms of the set of SLOs | bound". A network slice is expressed in terms of the set of SLOs | |||
that are to be delivered for the different connections between | that are to be delivered for the different connections between | |||
endpoints. | endpoints. | |||
A Service Level Agreement (SLA) is an explicit or implicit contract | A Service Level Agreement (SLA) is an explicit or implicit contract | |||
between the consumer of an IETF Network Slice and the provider of the | between the consumer of an IETF network slice and the provider of the | |||
slice. The SLA is expressed in terms of a set of SLOs and may | slice. The SLA is expressed in terms of a set of SLOs and may | |||
include commercial terms as well as the consequences of missing/ | include commercial terms as well as the consequences of missing/ | |||
violating the SLOs they contain. | violating the SLOs they contain. | |||
Additional descriptions of IETF network slice attributes is covered | Additional descriptions of IETF network slice attributes is covered | |||
in [I-D.contreras-teas-slice-nbi]. | in [I-D.contreras-teas-slice-nbi]. | |||
4.1.1. Service Level Objectives | 4.1.1. Service Level Objectives | |||
SLOs define a set of network attributes and characteristics that | SLOs define a set of network attributes and characteristics that | |||
skipping to change at page 6, line 19 ¶ | skipping to change at page 6, line 14 ¶ | |||
SLOs can be categorized in to 'Directly Measurable Objectives' or | SLOs can be categorized in to 'Directly Measurable Objectives' or | |||
'Indirectly Measurable Objectives'. Objectives such as guaranteed | 'Indirectly Measurable Objectives'. Objectives such as guaranteed | |||
minimum bandwidth, guaranteed maximum latency, maximum permissible | minimum bandwidth, guaranteed maximum latency, maximum permissible | |||
delay variation, maximum permissible packet loss rate, and | delay variation, maximum permissible packet loss rate, and | |||
availability are 'Directly Measurable Objectives'. While 'Indirectly | availability are 'Directly Measurable Objectives'. While 'Indirectly | |||
Measurable Objectives' include security, geographical restrictions, | Measurable Objectives' include security, geographical restrictions, | |||
maximum occupancy level objectives. The later standard might define | maximum occupancy level objectives. The later standard might define | |||
other SLOs as needed. | other SLOs as needed. | |||
Editor's Note TODO: Minimal set describes most commonly used | Editor's Note TODO: replace Minimal set to most commonly used | |||
objectives to describe network behavior. Other directly or | objectives to describe network behavior. Other directly or | |||
indirectly measurable objectives may be requested by that customer of | indirectly measurable objectives may be requested by that consumer of | |||
an IETF network slice. | an IETF network slice. | |||
The definition of these objectives are as follows: | The definition of these objectives are as follows: | |||
Guaranteed Minimum Bandwidth | Guaranteed Minimum Bandwidth | |||
Minimum guaranteed bandwidth between two endpoints at any time. | Minimum guaranteed bandwidth between two endpoints at any time. | |||
The bandwidth is measured in data rate units of bits per second | The bandwidth is measured in data rate units of bits per second | |||
and is measured unidirectionally. | and is measured unidirectionally. | |||
skipping to change at page 7, line 4 ¶ | skipping to change at page 6, line 48 ¶ | |||
difference in the one-way delay between sequential packets in a | difference in the one-way delay between sequential packets in a | |||
flow. This SLO sets a maximum value PDV for packets between | flow. This SLO sets a maximum value PDV for packets between | |||
two endpoints. | two endpoints. | |||
Maximum permissible packet loss rate | Maximum permissible packet loss rate | |||
The ratio of packets dropped to packets transmitted between two | The ratio of packets dropped to packets transmitted between two | |||
endpoints over a period of time. See [RFC7680] | endpoints over a period of time. See [RFC7680] | |||
Availability | Availability | |||
The ratio of uptime to the sum of uptime and downtime, where | The ratio of uptime to the sum of uptime and downtime, where | |||
uptime is the time the IETF network slice is available in | uptime is the time the IETF network slice is available in | |||
accordance with the SLOs associated with it. | accordance with the SLOs associated with it. | |||
Security | Security | |||
An IETF Network Slice consumer may request that the network | An IETF network slice consumer may request that the network | |||
applies encryption or other security techniques to traffic | applies encryption or other security techniques to traffic | |||
flowing between endpoints. | flowing between endpoints. | |||
Note that the use of security or the violation of this SLO is | Note that the use of security or the violation of this SLO is | |||
not directly observable by the IETF Network Slice consumer and | not directly observable by the IETF network slice consumer and | |||
cannot be measured as a quantifiable metric. | cannot be measured as a quantifiable metric. | |||
Also note that the objective may include request for encryption | Also note that the objective may include request for encryption | |||
(e.g., [RFC4303]) between the two endpoints explicitly to meet | (e.g., [RFC4303]) between the two endpoints explicitly to meet | |||
architecture recommendations as in [TS33.210] or for compliance | architecture recommendations as in [TS33.210] or for compliance | |||
with [HIPAA] and/or [PCI]. | with [HIPAA] and/or [PCI]. | |||
Editor's Note: Please see more discussion on security in | Editor's Note: Please see more discussion on security in | |||
Section 10. | Section 10. | |||
4.1.3. Other Objectives | 4.1.3. Other Objectives | |||
Additional SLOs may be defined to provide additional description of | Additional SLOs may be defined to provide additional description of | |||
the IETF network slice that a consumer requests. | the IETF network slice that a consumer requests. | |||
If the IETF Network Slice consumer service is traffic aware, other | If the IETF network slice consumer service is traffic aware, other | |||
traffic specific characteristics may be valuable including MTU, | traffic specific characteristics may be valuable including MTU, | |||
traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a | traffic-type (e.g., IPv4, IPv6, Ethernet or unstructured), or a | |||
higher-level behavior to process traffic according to user- | higher-level behavior to process traffic according to user- | |||
application (which may be realized using network functions). | application (which may be realized using network functions). | |||
Maximal occupancy for an IETF network slice should be provided. | Maximal occupancy for an IETF network slice should be provided. | |||
Since it carries traffic for multiple flows between the two | Since it carries traffic for multiple flows between the two | |||
endpoints, the objectives should also say if they are for the entire | endpoints, the objectives should also say if they are for the entire | |||
connection, group of flows or on per flow basis. Maximal occupancy | connection, group of flows or on per flow basis. Maximal occupancy | |||
should specify the scale of the flows (i.e. maximum number of flows | should specify the scale of the flows (i.e. maximum number of flows | |||
skipping to change at page 8, line 8 ¶ | skipping to change at page 8, line 5 ¶ | |||
4.2. IETF Network Slice Endpoints | 4.2. IETF Network Slice Endpoints | |||
As noted in Section 3, an IETF network slice describes connectivity | As noted in Section 3, an IETF network slice describes connectivity | |||
between endpoints across the underlying network. This connectivity | between endpoints across the underlying network. This connectivity | |||
may be be point-to-point, point-to-multipoint (P2MP), multipoint-to- | may be be point-to-point, point-to-multipoint (P2MP), multipoint-to- | |||
point, or multipoint-to-multipoint. | point, or multipoint-to-multipoint. | |||
The characteristics of IETF network slice endpoints (NSEs) are as | The characteristics of IETF network slice endpoints (NSEs) are as | |||
follows. | follows. | |||
o They are conceptual points of connection of a customer network, | o They are conceptual points of connection of a consumer network, | |||
network function, device, or application to the IETF network | network function, device, or application to the IETF network | |||
slice. This might include routers, switches, firewalls, WAN, | slice. This might include routers, switches, firewalls, WAN, | |||
4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep | 4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep | |||
Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], | Packet Inspection (DPI), server load balancers, NAT44 [RFC3022], | |||
NAT64 [RFC6146], HTTP header enrichment functions, and TCP | NAT64 [RFC6146], HTTP header enrichment functions, and TCP | |||
optimizers. | optimizers. | |||
o They are identified in a request provided by the consumer of an | o They are identified in a request provided by the consumer of an | |||
IETF Network Slice when the IETF Network Slice is requested. | IETF network slice when the IETF network slice is requested. | |||
o An NSE is identified a unique identifier and/or a unique name and | o An NSE is identified a unique identifier and/or a unique name and | |||
other data. A non-exhaustive list of other data includes IPv4 or | other data. A non-exhaustive list of other data includes IPv4 or | |||
IPv6 address, VLAN tag, port number, connectivity type (P2P, P2MP, | IPv6 address, VLAN tag, port number, connectivity type (P2P, P2MP, | |||
MP2MP). | MP2MP). | |||
Note that the NSE is different from access points (AP) defined in | Note that the NSE is different from access points (AP) defined in | |||
[RFC8453] as an AP is a logical identifier to identify the shared | [RFC8453] as an AP is a logical identifier to identify the shared | |||
link between the customer and the operator where as NSE is an | link between the consumer and the operator where as NSE is an | |||
identifier of an endpoint. Also NSE is different from TE Link | identifier of an endpoint. Also NSE is different from TE Link | |||
Termination Point (LTP) defined in [I-D.ietf-teas-yang-te-topo] as it | Termination Point (LTP) defined in [I-D.ietf-teas-yang-te-topo] as it | |||
is a conceptual point of connection of a TE node to one of the TE | is a conceptual point of connection of a TE node to one of the TE | |||
links on a TE node. | links on a TE node. | |||
The NSE is similar to the Termination Point (TP) defined in [RFC8345] | The NSE is similar to the Termination Point (TP) defined in [RFC8345] | |||
and can contain more attributes. NSE could be modeled by augmenting | and can contain more attributes. NSE could be modeled by augmenting | |||
the TP model. | the TP model. | |||
There is another type of the endpoints called "IETF Network Slice | There is another type of the endpoints called "IETF Network Slice | |||
Realization Endpoints (NSREs)". These endpoints are allocated and | Realization Endpoints (NSREs)". These endpoints are allocated and | |||
assigned by the network controller during the realization of an IETF | assigned by the network controller during the realization of an IETF | |||
Network Slice and are technology-specific, i.e. they depend on the | network slice and are technology-specific, i.e. they depend on the | |||
network technology used during the IETF Network Slice realization. | network technology used during the IETF network slice realization. | |||
The identification of NSREs forms part of the realization of the IETF | The identification of NSREs forms part of the realization of the IETF | |||
Network Slice and is implementation and deployment specific. | network slice and is implementation and deployment specific. | |||
Figure 1 shows an example of an IETF Network Slice and its | Figure 1 shows an example of an IETF network slice and its | |||
realization between multiple NSEs and NSREs. | realization between multiple NSEs and NSREs. | |||
(-------------------) | (-------------------) | |||
( IETF scoped Network ) | ( IETF scoped Network ) | |||
DAN1 ( ) DAN2 | DAN1 ( ) DAN2 | |||
-------- NSRE1 -------- -------- NSRE2 -------- | -------- NSRE1 -------- -------- NSRE2 -------- | |||
| o |-------o| A | | B |o--------| o | | | o |-------o| A | | B |o--------| o | | |||
| NSE1| -------- -------- | NSE2 | | | NSE1| -------- -------- | NSE2 | | |||
-------- | ( ) | -------- | -------- | ( ) | -------- | |||
| | ( ) | | | | | ( ) | | | |||
skipping to change at page 9, line 37 ¶ | skipping to change at page 9, line 37 ¶ | |||
4.2.1. IETF Network Slice Connectivity Types | 4.2.1. IETF Network Slice Connectivity Types | |||
The IETF Network Slice connection types can be point to point (P2P), | The IETF Network Slice connection types can be point to point (P2P), | |||
point to multipoint (P2MP), multi-point to point (MP2P), or multi- | point to multipoint (P2MP), multi-point to point (MP2P), or multi- | |||
point to multi-point (MP2MP). They will requested by the higher | point to multi-point (MP2MP). They will requested by the higher | |||
level operation system. | level operation system. | |||
4.3. IETF Network Slice Composition | 4.3. IETF Network Slice Composition | |||
Operationally, an IETF Network Slice maybe decomposed in two or more | Operationally, an IETF network slice maybe decomposed in two or more | |||
IETF Network Slices as specified below. Decomposed network slices | IETF network slices as specified below. Decomposed network slices | |||
are then independently realized and managed. | are then independently realized and managed. | |||
o Hierarchical (i.e., recursive) composition: An IETF Network Slice | o Hierarchical (i.e., recursive) composition: An IETF network slice | |||
can be further sliced into other network slices. Recursive | can be further sliced into other network slices. Recursive | |||
composition allows an IETF Network Slice at one layer to be used | composition allows an IETF network slice at one layer to be used | |||
by the other layers. This type of multi-layer vertical IETF | by the other layers. This type of multi-layer vertical IETF | |||
Network Slice associates resources at different layers. | network slice associates resources at different layers. | |||
o Sequential composition: Different IETF Network Slices can be | o Sequential composition: Different IETF network slices can be | |||
placed into a sequence to provide an end-to-end service. In | placed into a sequence to provide an end-to-end service. In | |||
sequential composition, each IETF Network Slice would potentially | sequential composition, each IETF network slice would potentially | |||
support different dataplanes that need to be stitched together. | support different dataplanes that need to be stitched together. | |||
5. IETF Network Slice Structure | 5. IETF Network Slice Structure | |||
Editor's note: This content of this section merged with Relationship | Editor's note: This content of this section merged with Relationship | |||
with E2E slice discussion. | with E2E slice discussion. | |||
An IETF Network Slice is a set of connections among various endpoints | An IETF network slice is a set of connections among various endpoints | |||
to form a logical network that meets the SLOs agreed upon. | to form a logical network that meets the SLOs agreed upon. | |||
____________________________ | ____________________________ | |||
[EP11]------/ /--[EP21] | [EP11]------/ /--[EP21] | |||
/ / | / / | |||
[EP12]----/ IETF Network Slice /----[EP22] | [EP12]----/ IETF Network Slice /----[EP22] | |||
: / (SLOs e.g. / | : / (SLOs e.g. / | |||
: / B/W > x bps, Delay < y ms)/ | : / B/W > x bps, Delay < y ms)/ | |||
[EP1m]-/___________________________/-------[EP2n] | [EP1m]-/___________________________/-------[EP2n] | |||
skipping to change at page 10, line 37 ¶ | skipping to change at page 10, line 37 ¶ | |||
: `-----------' `-----------' : | : `-----------' `-----------' : | |||
[EP1m] [EP2n] | [EP1m] [EP2n] | |||
Legend | Legend | |||
SLOs in terms of attributes, e.g. BW, delay. | SLOs in terms of attributes, e.g. BW, delay. | |||
EP: Endpoint | EP: Endpoint | |||
B/W: Bandwidth | B/W: Bandwidth | |||
Figure 2: IETF Network slice | Figure 2: IETF Network slice | |||
Figure 2 illustrates a case where an IETF Network Slice provides | Figure 2 illustrates a case where an IETF network slice provides | |||
connectivity between a set of endpoints pairs with specific | connectivity between a set of endpoints pairs with specific | |||
characteristics for each SLO (e.g. guaranteed minimum bandwidth of x | characteristics for each SLO (e.g. guaranteed minimum bandwidth of x | |||
bps and guaranteed delay of no more than y ms). The endpoints may be | bps and guaranteed delay of no more than y ms). The endpoints may be | |||
distributed in the underlay networks, and an IETF Network Slice can | distributed in the underlay networks, and an IETF network slice can | |||
be deployed across multiple network domains. Also, the endpoints on | be deployed across multiple network domains. Also, the endpoints on | |||
the same IETF Network Slice may belong to the same or different | the same IETF network slice may belong to the same or different | |||
address spaces. | address spaces. | |||
IETF Network slice structure fits into a broader concept of end-to- | IETF Network slice structure fits into a broader concept of end-to- | |||
end network slices. A network operator may be responsible for | end network slices. A network operator may be responsible for | |||
delivering services over a number of technologies (such as radio | delivering services over a number of technologies (such as radio | |||
networks) and for providing specific and fine-grained services (such | networks) and for providing specific and fine-grained services (such | |||
as CCTV feed or High definition realtime traffic data). That | as CCTV feed or High definition realtime traffic data). That | |||
operator may need to combine slices of various networks to produce an | operator may need to combine slices of various networks to produce an | |||
end-to-end network service. Each of these networks may include | end-to-end network service. Each of these networks may include | |||
multiple physical or virtual nodes and may also provide network | multiple physical or virtual nodes and may also provide network | |||
functions beyond simply carrying of technology-specific protocol data | functions beyond simply carrying of technology-specific protocol data | |||
units.An end-to-end network slice is defined by the 3GPP as a | units.An end-to-end network slice is defined by the 3GPP as a | |||
complete logical network that provides a service in its entirety with | complete logical network that provides a service in its entirety with | |||
a specific assurance to the customer [TS.23.501-3GPP]. | a specific assurance to the consumer [TS.23.501-3GPP]. | |||
An end-to-end network slice may be composed from other network slices | An end-to-end network slice may be composed from other network slices | |||
that include IETF Network Slices. This composition may include the | that include IETF network slices. This composition may include the | |||
hierarchical (or recursive) use of underlying network slices and the | hierarchical (or recursive) use of underlying network slices and the | |||
sequential (or stitched) combination of slices of different networks. | sequential (or stitched) combination of slices of different networks. | |||
6. IETF Network Slice Stakeholders | 6. IETF Network Slice Stakeholders | |||
An IETF Network Slice and its realization involves the following | An IETF network slice and its realization involves the following | |||
stakeholders and it is relevant to define them for consistent | stakeholders and it is relevant to define them for consistent | |||
terminology. | terminology. | |||
Consumer: A consumer is the requester of an IETF Network Slice. | Consumer: A consumer is the requester of an IETF network slice. | |||
Consumers may request monitoring of SLOs. A consumer may manage | Consumers may request monitoring of SLOs. A consumer may manage | |||
the IETF Network Slice service directly by interfacing with the | the IETF network slice service directly by interfacing with the | |||
IETF Network Slice controller or indirectly through an | IETF network slice controller or indirectly through an | |||
orchestrator. | orchestrator. | |||
Orchestrator: An orchestrator is an entity that composes different | Orchestrator: An orchestrator is an entity that composes different | |||
services, resource and network requirements. It interfaces with | services, resource and network requirements. It interfaces with | |||
the IETF Network Slice controllers. | the IETF network slice controllers. | |||
IETF Network Slice Controller (NSC): It realizes an IETF Network | IETF Network Slice Controller (NSC): It realizes an IETF network | |||
Slice in the underlying network, maintains and monitors the run- | lice in the underlying network, maintains and monitors the run- | |||
time state of resources and topologies associated with it. A | time state of resources and topologies associated with it. A | |||
well-defined interface is needed between different types of IETF | well-defined interface is needed between different types of IETF | |||
Network Slice controllers and different types of orchestrators. | network slice controllers and different types of orchestrators. | |||
An IETF Network Slice operator (or slice operator for short) | An IETF network slice operator (or slice operator for short) | |||
manages one or more IETF Network Slices using the IETF Network | manages one or more IETF network slices using the IETF network | |||
Slice Controller(s). | slice Controller(s). | |||
Network Controller: is a form of network infrastructure controller | Network Controller: is a form of network infrastructure controller | |||
that offers network resources to NSC to realize a particular | that offers network resources to NSC to realize a particular | |||
network slice. These may be existing network controllers | network slice. These may be existing network controllers | |||
associated with one or more specific technologies that may be | associated with one or more specific technologies that may be | |||
adapted to the function of realizing IETF Network Slices in a | adapted to the function of realizing IETF network slices in a | |||
network. | network. | |||
7. IETF Network Slice Controller Interfaces | 7. IETF Network Slice Controller Interfaces | |||
The interworking and interoperability among the different | The interworking and interoperability among the different | |||
stakeholders to provide common means of provisioning, operating and | stakeholders to provide common means of provisioning, operating and | |||
monitoring the IETF Network slices is enabled by the following | monitoring the IETF Network slices is enabled by the following | |||
communication interfaces (see Figure 3). | communication interfaces (see Figure 3). | |||
NSC Northbound Interface (NBI): The NSC Northbound Interface is an | NSC Northbound Interface (NBI): The NSC Northbound Interface is an | |||
interface between a consumer's higher level operation system | interface between a consumer's higher level operation system | |||
(e.g., a network slice orchestrator) and the NSC. It is a | (e.g., a network slice orchestrator) and the NSC. It is a | |||
technology agnostic interface. The consumer can use this | technology agnostic interface. The consumer can use this | |||
interface to communicate the requested characteristics and other | interface to communicate the requested characteristics and other | |||
requirements (i.e., the SLOs) for the IETF Network Slice, and the | requirements (i.e., the SLOs) for the IETF network slice, and the | |||
NSC can use the interface to report the operational state of an | NSC can use the interface to report the operational state of an | |||
IETF Network Slice to the consumer. | IETF network slice to the consumer. | |||
NSC Southbound Interface (SBI): The NSC Southbound Interface is an | NSC Southbound Interface (SBI): The NSC Southbound Interface is an | |||
interface between the NSC and network controllers. It is | interface between the NSC and network controllers. It is | |||
technology-specific and may be built around the many network | technology-specific and may be built around the many network | |||
models defined within the IETF. | models defined within the IETF. | |||
+------------------------------------------+ | +------------------------------------------+ | |||
| Consumer higher level operation system | | | Consumer higher level operation system | | |||
| (e.g E2E network slice orchestrator) | | | (e.g E2E network slice orchestrator) | | |||
+------------------------------------------+ | +------------------------------------------+ | |||
skipping to change at page 12, line 47 ¶ | skipping to change at page 12, line 47 ¶ | |||
| NSC SBI | | NSC SBI | |||
V | V | |||
+------------------------------------------+ | +------------------------------------------+ | |||
| Network Controllers | | | Network Controllers | | |||
+------------------------------------------+ | +------------------------------------------+ | |||
Figure 3: Interface of IETF Network Slice Controller | Figure 3: Interface of IETF Network Slice Controller | |||
8. Realizing IETF Network Slice | 8. Realizing IETF Network Slice | |||
Realization of IETF Network Slices is out of scope of this document. | Realization of IETF network slices is out of scope of this document. | |||
It is a mapping of the definition of the IETF Network Slice to the | It is a mapping of the definition of the IETF network slice to the | |||
underlying infrastructure and is necessarily technology-specific and | underlying infrastructure and is necessarily technology-specific and | |||
achieved by the NSC over the SBI. | achieved by the NSC over the SBI. | |||
The realization can be achieved in a form of either physical or | The realization can be achieved in a form of either physical or | |||
logical connectivity through VPNs (see, for example, | logical connectivity through VPNs (see, for example, | |||
[I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies | [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies | |||
such as Segment Routing, MPLS, etc. Accordingly, endpoints may be | such as Segment Routing, MPLS, etc. Accordingly, endpoints may be | |||
realized as physical or logical service or network functions. | realized as physical or logical service or network functions. | |||
9. Isolation in IETF Network Slices | 9. Isolation in IETF Network Slices | |||
Editor's note: This content is a work in progress. The section on | An IETF network slice consumer may request, that the IETF Network | |||
isolation is too descriptive. | ||||
An IETF Network Slice consumer may request, that the IETF Network | ||||
Slice delivered to them is isolated from any other network slices of | Slice delivered to them is isolated from any other network slices of | |||
services delivered to any other customers. It is expected that the | services delivered to any other consumers. It is expected that the | |||
changes to the other network slices of services do not have any | changes to the other network slices of services do not have any | |||
negative impact on the delivery of the IETF Network Slice. In a more | negative impact on the delivery of the IETF network slice. | |||
general sense, isolation can be classified in the following ways: | ||||
Traffic Separation: Traffic of one network slice should not be | ||||
subjected to policies and forwarding rules of other network | ||||
slices. | ||||
Interference Avoidance: Changes in other network slices should not | ||||
impact to the SLOs of the network slice. Here the changes in | ||||
other network slice may include the changes in connectivity, | ||||
traffic volume, traffic pattern, etc. | ||||
Service Assurance: In case service degradation is unacceptable due | ||||
to unpredictable network situations producing service degradation | ||||
(e.g., major congestion events, etc.), explicit reservation of | ||||
resources in the network maybe requested for a reduces set IETF | ||||
network slices. | ||||
9.1. Isolation as a Service Requirement | 9.1. Isolation as a Service Requirement | |||
Isolation is an important requirement of IETF network slices for | Isolation may be an important requirement of IETF network slices for | |||
services like critical services, emergencies, etc. A consumer may | some critical services. A consumer may express this request as an | |||
express this request through the description of SLOs. | SLO. | |||
This requirement can be met by simple conformance with other SLOs. | This requirement can be met by simple conformance with other SLOs. | |||
For example, traffic congestion (interference from other services) | For example, traffic congestion (interference from other services) | |||
might impact on the latency experienced by an IETF network slice. | might impact on the latency experienced by an IETF network slice. | |||
Thus, in this example, conformance to a latency SLO would be the | Thus, in this example, conformance to a latency SLO would be the | |||
primary requirement for delivery of the IETF network slice service, | primary requirement for delivery of the IETF network slice service, | |||
and isolation from other services might be only a means to that end. | and isolation from other services might be only a means to that end. | |||
It should be noted that some aspects of isolation may be measurable | It should be noted that some aspects of isolation may be measurable | |||
by a customer who have the information about the traffic on a number | by a consumer who have the information about the traffic on a number | |||
of IETF network slices or other services. | of IETF network slices or other services. | |||
9.2. Isolation in IETF Network Slice Realization | 9.2. Isolation in IETF Network Slice Realization | |||
The isolation requirement can be achieved with existing, in- | Delivery of isolation is achieved in the realization of IETF network | |||
development, and potential new technologies in IETF. | slices, with existing, in-development, and potential new technologies | |||
in IETF. It depends on how a network operator decides to operate | ||||
their network and deliver services. | ||||
Isolation may be achieved in the underlying network by various forms | Isolation may be achieved in the underlying network by various forms | |||
of resource partitioning ranging from dedicated allocation of | of resource partitioning ranging from dedicated allocation of | |||
resources for a specific IETF network slice, to sharing or resources | resources for a specific IETF network slice, to sharing or resources | |||
with safeguards. For example, traffic separation between different | with safeguards. For example, traffic separation between different | |||
IETF network slices may be achieved using VPN technologies, such as | IETF network slices may be achieved using VPN technologies, such as | |||
L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by | L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by | |||
network capacity planning, allocating dedicated network resources, | network capacity planning, allocating dedicated network resources, | |||
traffic policing or shaping, prioritizing in using shared network | traffic policing or shaping, prioritizing in using shared network | |||
resources, etc. Finally, service continuity may be ensured by | resources, etc. Finally, service continuity may be ensured by | |||
reserving backup paths for critical traffic, dedicating specific | reserving backup paths for critical traffic, dedicating specific | |||
network resources for a selected number of network slices, etc. | network resources for a selected number of network slices, etc. | |||
9.3. Relationship with Isolation in 5G Network Slice | ||||
Editor's note: This 5G subsection should not be added to terminology. | ||||
it does not add value to the definitions. | ||||
In the context of 5G network slice, "isolation level" is listed as | ||||
one of the attributes which can be used to characterize the type of | ||||
network slice [GSMA Generic Network Slice Template]. For 5G network | ||||
slice, different types of isolation are considered, including | ||||
physical and logical isolation. Physical isolation refers to | ||||
different physical network entities, and logical isolation is further | ||||
classified into virtual resource isolation, network function | ||||
isolation and tenant/service isolation. | ||||
10. Security Considerations | 10. Security Considerations | |||
Editor's Note: Need further improvement; work in progress. | ||||
This document specifies terminology and has no direct effect on the | This document specifies terminology and has no direct effect on the | |||
security of implementations or deployments. | security of implementations or deployments. In this section, a few | |||
of the security aspects are identified. | ||||
As noted in Section 4.1.2, some aspects of security may be expressed | o Conformance to security constraints: Specific security requests | |||
in SLOs and so form part of the service delivered as an IETF network | from consumer defined IETF network slices will be mapped to their | |||
slice. As further mentioned in Section 8, there is an underlying | realization in the unerlay networks. It will be required by | |||
asumption that traffic presented to an IETF network slice will not be | underlay networks to have capabilities to conform to consumer's | |||
misdelivered to an endpoint that is not part of that IETF network | requests as some aspects of security may be expressed in SLOs. | |||
slice. | ||||
Furthermore, the nature of conformance to SLOs means that it should | o IETF network slice controller authentication: Unerlying networks | |||
not be possible to attack an IETF network slice service by varying | need to be protected against the attacks from an adversary NSC as | |||
the traffic on other services or slices carried by the same underlay | they can destablize overall network operations. It is | |||
network. This concern can be strengthened by the stipulation of | particularly critical since an IETF network slice may span across | |||
"isolation" as an SLO. | different networks, therefore, IETF NSC should have strong | |||
authentication with each those networks. Futhermore, both SBI and | ||||
NBI need to be secured. | ||||
Note, however, that a customer wanting to secure their data and keep | o Specific isolation criteria: The nature of conformance to | |||
it private will be responsible for applying appropriate security | isolation requests means that it should not be possible to attack | |||
measures to their traffic and not depending on the network operator | an IETF network slice service by varying the traffic on other | |||
that provides the IETF network slice. | services or slices carried by the same underlay network. In | |||
general, isolation is expected to strengthen the IETF network | ||||
slice security. | ||||
o Data Integrity of an IETF network slice: A consumer wanting to | ||||
secure their data and keep it private will be responsible for | ||||
applying appropriate security measures to their traffic and not | ||||
depending on the network operator that provides the IETF network | ||||
slice. It is expected that for data integrity, a consumer is | ||||
responsible for end-to-end encryption of its own traffic. | ||||
Note: see NGMN document [NGMN_SEC] on 5G network slice security for | ||||
discussion relevant to this section. | ||||
11. IANA Considerations | 11. IANA Considerations | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
12. Acknowledgment | 12. Acknowledgment | |||
The entire TEAS NS design team and everyone participating in those | The entire TEAS NS design team and everyone participating in those | |||
discussion has contributed to this draft. Particularly, Eric Gray, | discussion has contributed to this draft. Particularly, Eric Gray, | |||
Xufeng Liu, Jie Dong, Adrian Farrel, and Jari Arkko for a thorough | Xufeng Liu, Jie Dong, Adrian Farrel, and Jari Arkko for a thorough | |||
skipping to change at page 16, line 10 ¶ | skipping to change at page 15, line 42 ¶ | |||
Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and | Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and | |||
O. Dios, "YANG Data Model for Traffic Engineering (TE) | O. Dios, "YANG Data Model for Traffic Engineering (TE) | |||
Topologies", draft-ietf-teas-yang-te-topo-22 (work in | Topologies", draft-ietf-teas-yang-te-topo-22 (work in | |||
progress), June 2019. | progress), June 2019. | |||
[I-D.nsdt-teas-ns-framework] | [I-D.nsdt-teas-ns-framework] | |||
Gray, E. and J. Drake, "Framework for Transport Network | Gray, E. and J. Drake, "Framework for Transport Network | |||
Slices", draft-nsdt-teas-ns-framework-02 (work in | Slices", draft-nsdt-teas-ns-framework-02 (work in | |||
progress), March 2020. | progress), March 2020. | |||
[NGMN_SEC] | ||||
NGMN Alliance, "NGMN 5G Security - Network Slicing", April | ||||
2016, <https://www.ngmn.org/wp-content/uploads/Publication | ||||
s/2016/160429_NGMN_5G_Security_Network_Slicing_v1_0.pdf>. | ||||
[PCI] PCI Security Standards Council, "PCI DSS", May 2018, | [PCI] PCI Security Standards Council, "PCI DSS", May 2018, | |||
<https://www.pcisecuritystandards.org>. | <https://www.pcisecuritystandards.org>. | |||
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip | |||
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, | Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, | |||
September 1999, <https://www.rfc-editor.org/info/rfc2681>. | September 1999, <https://www.rfc-editor.org/info/rfc2681>. | |||
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network | |||
Address Translator (Traditional NAT)", RFC 3022, | Address Translator (Traditional NAT)", RFC 3022, | |||
DOI 10.17487/RFC3022, January 2001, | DOI 10.17487/RFC3022, January 2001, | |||
End of changes. 65 change blocks. | ||||
145 lines changed or deleted | 131 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |