< draft-ietf-detnet-mpls-over-udp-ip-00.txt   draft-ietf-detnet-mpls-over-udp-ip-01.txt >
DetNet B. Varga, Ed. DetNet B. Varga, Ed.
Internet-Draft J. Farkas Internet-Draft J. Farkas
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: November 6, 2019 L. Berger Expires: January 2, 2020 L. Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
A. Malis A. Malis
S. Bryant S. Bryant
Huawei Technologies Futurewei Technologies
J. Korhonen J. Korhonen
May 5, 2019 July 1, 2019
DetNet Data Plane: MPLS over IP DetNet Data Plane: MPLS over UDP/IP
draft-ietf-detnet-mpls-over-udp-ip-00 draft-ietf-detnet-mpls-over-udp-ip-01
Abstract Abstract
This document specifies the MPLS Deterministic Networking data plane This document specifies the MPLS Deterministic Networking data plane
operation and encapsulation over an IP network. The approach is operation and encapsulation over an IP network. The approach is
modeled on the operation of MPLS and PseudoWires (PW) over IP. modeled on the operation of MPLS and over UDP/IP packet switched
networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 6, 2019. This Internet-Draft will expire on January 2, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 15 skipping to change at page 2, line 16
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3 2.1. Terms Used in This Document . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
4. DetNet MPLS Operation over DetNet 3. DetNet MPLS Operation over DetNet
IP PSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 IP PSNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. DetNet Data Plane Procedures . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Management and Control Information Summary . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Deterministic Networking (DetNet) is a service that can be offered by Deterministic Networking (DetNet) is a service that can be offered by
a network to DetNet flows. DetNet provides these flows with a low a network to DetNet flows. DetNet provides these flows with a low
packet loss rates and assured maximum end-to-end delivery latency. packet loss rates and assured maximum end-to-end delivery latency.
General background and concepts of DetNet can be found in General background and concepts of DetNet can be found in
[I-D.ietf-detnet-architecture]. [I-D.ietf-detnet-architecture].
The DetNet Architecture decomposes the DetNet related data plane
functions into two sub-layers: a service sub-layer and a forwarding
sub-layer. The service sub-layer is used to provide DetNet service
protection and reordering. The forwarding sub-layer is used to
provides congestion protection (low loss, assured latency, and
limited reordering) leveraging MPLS Traffic Engineering mechanisms.
This document specifies use of the MPLS DetNet encapsulation over an This document specifies use of the MPLS DetNet encapsulation over an
IP network. The approach is modeled on the operation of MPLS and IP network. The approach is modeled on the operation of MPLS over an
PseudoWires (PW) over an IP Packet Switched Network (PSN) IP Packet Switched Network (PSN) [RFC7510]. It maps the MPLS data
[RFC3985][RFC4385][RFC7510]. It maps the MPLS data plane plane encapsulation described in [I-D.ietf-detnet-mpls] to the DetNet
encapsulation described in [I-D.ietf-detnet-mpls] to the DetNet IP IP data plane defined in [I-D.ietf-detnet-ip].
data plane defined in [I-D.ietf-detnet-ip].
To carry DetNet with full functionality at the DetNet layer over an To carry DetNet flows with full functionality at the DetNet layer
IP network, the following components are required (these are a subset over an IP network, the following components are required (these are
of the requirements for MPLS encapsulation listed in a subset of the requirements for MPLS encapsulation listed in
[I-D.ietf-detnet-mpls]): [I-D.ietf-detnet-mpls]):
1. A method of identifying the DetNet flow group to the processing 1. A method of identifying the DetNet flow group to the processing
element. element.
2. A method of carrying the DetNet sequence number. 2. A method of carrying the DetNet sequence number.
3. A method of distinguishing DetNet OAM packets from DetNet data 3. A method of distinguishing DetNet OAM packets from DetNet data
packets. packets.
4. A method of carrying queuing and forwarding indication. 4. A method of carrying queuing and forwarding indication.
These requirements are satisfied by the DetNet over MPLS These requirements are satisfied by the DetNet over MPLS
Encapsulation described in [I-D.ietf-detnet-mpls]. Encapsulation described in [I-D.ietf-detnet-mpls] and they are partly
satisfied by the DetNet IP data plane defined in [I-D.ietf-detnet-ip]
2. Terminology 2. Terminology
2.1. Terms Used in This Document 2.1. Terms Used in This Document
This document uses the terminology established in the DetNet This document uses the terminology established in the DetNet
architecture [I-D.ietf-detnet-architecture], and the reader is architecture [I-D.ietf-detnet-architecture], and the reader is
assumed to be familiar with that document and its terminology. assumed to be familiar with that document and its terminology.
2.2. Abbreviations 2.2. Abbreviations
The following abbreviations are used in this document: The following abbreviations are used in this document:
CW Control Word.
d-CW A DetNet Control Word (d-CW) is used for sequencing and d-CW A DetNet Control Word (d-CW) is used for sequencing and
identifying duplicate packets of a DetNet flow at the identifying duplicate packets of a DetNet flow at the
DetNet service sub-layer. DetNet service sub-layer.
DetNet Deterministic Networking. DetNet Deterministic Networking.
A-Label A special case of an S-Label, whose properties are
known only at the aggregation and deaggregation end-
points.
F-Label A Detnet "forwarding" label that identifies the LSP F-Label A Detnet "forwarding" label that identifies the LSP
used to forward a DetNet flow across an MPLS PSN, e.g., used to forward a DetNet flow across an MPLS PSN, e.g.,
a hop-by-hop label used between label switching routers a hop-by-hop label used between label switching
(LSR). routers.
LSR Label Switching Router.
MPLS Multiprotocol Label Switching. MPLS Multiprotocol Label Switching.
OAM Operations, Administration, and Maintenance. OAM Operations, Administration, and Maintenance.
PEF Packet Elimination Function. PEF Packet Elimination Function.
PRF Packet Replication Function.
PREOF Packet Replication, Elimination and Ordering Functions.
POF Packet Ordering Function. POF Packet Ordering Function.
PSN Packet Switched Network. PRF Packet Replication Function.
PW PseudoWire. PSN Packet Switched Network.
S-Label A DetNet "service" label that is used between DetNet S-Label A DetNet "service" label that is used between DetNet
nodes that implement also the DetNet service sub-layer nodes that implement also the DetNet service sub-layer
functions. An S-Label is also used to identify a functions. An S-Label is also used to identify a
DetNet flow at DetNet service sub-layer. DetNet flow at DetNet service sub-layer.
3. Requirements Language 2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. DetNet MPLS Operation over DetNet IP PSNs 3. DetNet MPLS Operation over DetNet IP PSNs
This document builds on the specification of MPLS over UDP and IP This document builds on the specification of MPLS over UDP defined in
defined in [RFC7510]. It replaces the F-Label(s) used in [RFC7510]. It may replace partly or entirely the F-Label(s) used in
[I-D.ietf-detnet-mpls] with UDP and IP headers. The UDP and IP [I-D.ietf-detnet-mpls] with UDP and IP headers. The UDP and IP
header information is used to identify DetNet flows, including member header information is used to identify DetNet flows, including member
flows, per [I-D.ietf-detnet-ip]. The resulting encapsulation is flows, per [I-D.ietf-detnet-ip]. The resulting encapsulation is
shown in Figure 1. shown in Figure 1. There may be zero or more F-label(s) between the
S-label and the UDP header.
Note that this encapsulation works equally well with IPv4, IPv6, and Note that this encapsulation works equally well with IPv4, IPv6, and
IPv6-based Segment Routing [I-D.ietf-6man-segment-routing-header]. IPv6-based Segment Routing [I-D.ietf-6man-segment-routing-header].
+---------------------------------+ +---------------------------------+
| | | |
| DetNet App-Flow | | DetNet App-Flow |
| Payload Packet | | Payload Packet |
| | | |
+---------------------------------+ <--\ +---------------------------------+ <--\
| DetNet Control Word | | | DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane +---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation | S-Label | | MPLS encapsulation
+---------------------------------+ |
| [ F-label(s) ] | |
+---------------------------------+ <--+ +---------------------------------+ <--+
| UDP Header | | | UDP Header | |
+---------------------------------+ +--> DetNet data plane +---------------------------------+ +--> DetNet data plane
| IP Header | | IP encapsulation | IP Header | | IP encapsulation
+---------------------------------+ <--/ +---------------------------------+ <--/
| Data-Link | | Data-Link |
+---------------------------------+ +---------------------------------+
| Physical | | Physical |
+---------------------------------+ +---------------------------------+
Figure 1: IP Encapsulation of DetNet MPLS Figure 1: UDP/IP Encapsulation of DetNet MPLS
d-CW and and S-Labels are used as defined in [I-D.ietf-detnet-mpls]
and are not modified by this document.
To support outgoing DetNet MPLS over IP, an implementation MUST d-CW, S-Labels and zero or more F-Labels are used as defined in
support the provisioning of IP/UDP header information in place of [I-D.ietf-detnet-mpls] and are not modified by this document. In
sets of F-Labels. Note that multiple sets of F-Labels can be case of aggregates the A-Label is treated as an S-Label and it too is
provisioned to support PRF on transmitted DetNet flows and therefore, not modified.
when PRF is supported, multiple IP/UDP headers MAY be provisioned.
When multiple IP/UDP headers are provisioned for a particular
outgoing app-flow, a copy of the outgoing packet, including the
pushed S-Label, MUST be made for each. The headers for each outgoing
packet MUST be based on the configuration information and as defined
in [RFC7510], with one exception. The one exception is that the UDP
Source Port value MUST be set to uniquely identify the DetNet
(forwarding sub-layer) flow. The packet MUST then be handed as a
DetNet IP packet, per [I-D.ietf-detnet-ip].
To support receive processing an implementation MUST also support the 4. DetNet Data Plane Procedures
provisioning of received IP/UDP header information. When S-Labels
are taken from platform label space, all that is required is to
provision that receiving IP/UDP encapsulated DetNet MPLS packets is
permitted. Once the IP/UDP header is stripped, the S-label uniquely
identifies the app-flow. When S-Labels are not taken from platform
label space, IP/UDP header information MUST be provisioned. The
provisioned information MUST then be used to identify incoming app-
flows based on the combination of S-Label and incoming IP/UDP header.
Normal receive processing, including PEOF can then take place.
5. Security Considerations To support outgoing DetNet MPLS over UDP/IP encapsulation, an
implementation MUST support the provisioning of UDP and IP header
information in addition or in place of F-Label(s). Note, when PRF is
performed at the MPLS service sub-layer, there will be multiple
member flows, and each member flow will require the provisioning of
their own UDP and IP header information. The headers for each
outgoing packet MUST be formatted on the configuration information
and as defined in [RFC7510], with one exception. Note that the UDP
Source Port value MUST be set to uniquely identify the DetNet flow.
The packet MUST then be handed as a DetNet IP packet, per
[I-D.ietf-detnet-ip]. This includes QoS related traffic treatment.
The security considerations of DetNet in general are discussed in To support receive processing an implementation MUST also support the
[I-D.ietf-detnet-architecture] and [I-D.sdt-detnet-security]. Other provisioning of received UDP and IP header information. The
security considerations will be added in a future version of this provisioned information MUST be used to identify incoming app-flows
draft. based on the combination of S-Label and incoming encapsulation header
information. Normal receive processing as defined in
[I-D.ietf-detnet-mpls], including PEF and POF, can then take place.
6. IANA Considerations 5. Management and Control Information Summary
This document makes no IANA requests. The following summarizes the set of information that is needed to
configure DetNet MPLS over UDP/IP:
7. Contributors o Label information (S-label or F-label) to be mapped to UDP/IP
flow. Note that a single S-Label can map to multiple sets of UPD/
IP information when PREOF is used.
RFC7322 limits the number of authors listed on the front page of a o IPv4 and IPv6 source address field.
draft to a maximum of 5, far fewer than the many individuals below
who made important contributions to this draft. The editor wishes to
thank and acknowledge each of the following authors for contributing
text to this draft. See also Section 8.
Loa Andersson o IPv4 and IPv6 destination address field.
Huawei
Email: loa@pi.nu
Yuanlong Jiang o IPv4 Type of Service and IPv6 Traffic Class Fields.
Huawei
Email: jiangyuanlong@huawei.com
Norman Finn o UDP Source Port.
Huawei
3101 Rio Way
Spring Valley, CA 91977
USA
Email: norman.finn@mail01.huawei.com
Janos Farkas o UDP Destination Port.
Ericsson
Magyar Tudosok krt. 11.
Budapest 1117
Hungary
Email: janos.farkas@ericsson.com
Carlos J. Bernardos This information MUST be provisioned per DetNet flow via
Universidad Carlos III de Madrid configuration, e.g., via the controller or management plane.
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Email: cjbc@it.uc3m.es
Tal Mizrahi It is the responsibility of the DetNet controller plane to properly
Marvell provision both flow identification information and the flow specific
6 Hamada st. resources needed to provided the traffic treatment needed to meet
Yokneam each flow's service requirements. This applies for aggregated and
Israel individual flows.
Email: talmi@marvell.com
Lou Berger 6. Security Considerations
LabN Consulting, L.L.C.
Email: lberger@labn.net
Stewart Bryant The security considerations of DetNet in general are discussed in
Huawei Technologies [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security]. MPLS
Email: stewart.bryant@gmail.com and IP specific security considerations are described in
[I-D.ietf-detnet-mpls] and [I-D.ietf-detnet-ip]. This draft does not
have additional security considerations.
Mach Chen 7. IANA Considerations
Huawei Technologies
Email: mach.chen@huawei.com
Andrew G. Malis This document makes no IANA requests.
Huawei Technologies
Email: agmalis@gmail.com
8. Acknowledgements 8. Acknowledgements
The author(s) ACK and NACK. The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson,
David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David
The following people were part of the DetNet Data Plane Solution Mozes, Craig Gunther, George Swallow, Yuanlong Jiang and Carlos J.
Design Team: Bernardos for their various contributions to this work.
Jouni Korhonen
Janos Farkas
Norman Finn
Balazs Varga
Loa Andersson
Tal Mizrahi
David Mozes
Yuanlong Jiang
Andrew Malis
Carlos J. Bernardos
The DetNet chairs serving during the DetNet Data Plane Solution
Design Team:
Lou Berger
Pat Thaler
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-detnet-ip] [I-D.ietf-detnet-ip]
Korhonen, J., Varga, B., "DetNet IP", 2019. Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: IP",
draft-ietf-detnet-ip-00 (work in progress), May 2019.
[I-D.ietf-detnet-mpls] [I-D.ietf-detnet-mpls]
Korhonen, J., Varga, B., "DetNet MPLS", 2019. Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A.,
Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS",
draft-ietf-detnet-mpls-00 (work in progress), May 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, "Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015, DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>. <https://www.rfc-editor.org/info/rfc7510>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
(SRH)", draft-ietf-6man-segment-routing-header-18 (work in Routing Header (SRH)", draft-ietf-6man-segment-routing-
progress), April 2019. header-21 (work in progress), June 2019.
[I-D.ietf-detnet-architecture] [I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas, Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf- "Deterministic Networking Architecture", draft-ietf-
detnet-architecture-12 (work in progress), March 2019. detnet-architecture-13 (work in progress), May 2019.
[I-D.sdt-detnet-security]
Mizrahi, T., Grossman, E., Hacker, A., Das, S.,
"Deterministic Networking (DetNet) Security
Considerations, draft-sdt-detnet-security, work in
progress", 2017.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [I-D.ietf-detnet-security]
Edge-to-Edge (PWE3) Architecture", RFC 3985, Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
DOI 10.17487/RFC3985, March 2005, J., Austad, H., Stanton, K., and N. Finn, "Deterministic
<https://www.rfc-editor.org/info/rfc3985>. Networking (DetNet) Security Considerations", draft-ietf-
detnet-security-04 (work in progress), March 2019.
Authors' Addresses Authors' Addresses
Balazs Varga (editor) Balazs Varga (editor)
Ericsson Ericsson
Magyar Tudosok krt. 11. Magyar Tudosok krt. 11.
Budapest 1117 Budapest 1117
Hungary Hungary
Email: balazs.a.varga@ericsson.com Email: balazs.a.varga@ericsson.com
skipping to change at page 9, line 45 skipping to change at page 8, line 35
Hungary Hungary
Email: janos.farkas@ericsson.com Email: janos.farkas@ericsson.com
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Andrew G. Malis Andrew G. Malis
Huawei Technologies Futurewei Technologies
Email: agmalis@gmail.com Email: agmalis@gmail.com
Stewart Bryant Stewart Bryant
Huawei Technologies Futurewei Technologies
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Jouni Korhonen Jouni Korhonen
Email: jouni.nospam@gmail.com Email: jouni.nospam@gmail.com
 End of changes. 52 change blocks. 
186 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/