< draft-ietf-bier-path-mtu-discovery-00.txt   draft-ietf-bier-path-mtu-discovery-01.txt >
BIER Working Group G. Mirsky BIER Working Group G. Mirsky
Internet-Draft Ericsson Internet-Draft ZTE Corp.
Intended status: Standards Track T. Przygienda Intended status: Standards Track T. Przygienda
Expires: January 19, 2017 Juniper Networks Expires: July 21, 2017 Juniper Networks
A. Dolganow A. Dolganow
Nokia Nokia
July 18, 2016 January 17, 2017
Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit
Replication (BIER) Layer Replication (BIER) Layer
draft-ietf-bier-path-mtu-discovery-00 draft-ietf-bier-path-mtu-discovery-01
Abstract Abstract
This document describes Path Maximum Transmission Unit Discovery This document describes Path Maximum Transmission Unit Discovery
(PMTUD) in Bit Indexed Explicit Replication (BIER) layer. (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
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.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 19, 2017. This Internet-Draft will expire on July 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4 3. PMTUD Mechanism for BIER . . . . . . . . . . . . . . . . . . 4
3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6 3.1. Data TLV for BIER Ping . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
In packet switched networks when a host seeks to transmit a sizable In packet switched networks, when a host seeks to transmit data to a
amount of data to a target destination the data is transmitted as a target destination, the data is transmitted as a set of packets. In
set of datagrams. In most cases it is more efficient to use the many cases it is more efficient to use the largest size packets that
largest possible datagrams but so that these datagrams do not have to are less than or equal to the least Maximum Transmission Unit (MTU)
be fragmented at any point along the path from the host to the for any forwarding device along the routed path to the IP destination
destination in order to avoid performance degradation caused by for these packets. Such "least MTU" is known as Path MTU (PMTU).
fragmentation. Fragmentation occurs on hops along the route where an Fragmentation or packet drop, silent or not, may occur on hops along
Maximum Transmission Unit (MTU) is smaller than the size of the the route where a MTU is smaller than the size of the datagram. To
datagram. To avoid such fragmentation the MTU for each hop along a avoid any of the listed above behaviors, the packet source must find
path from a host to a destination must be known to select an the value of the least MTU, i.e. PMTU, that will be encountered along
appropriate datagram size. Such MTU determination along a specific the route that a set of packets will follow to reach the given set of
path is referred to as path MTU discovery (PMTUD). destinations. Such MTU determination along a specific path is
referred to as path MTU discovery (PMTUD).
[I-D.ietf-bier-architecture] introduces and explains Bit Index [I-D.ietf-bier-architecture] introduces and explains Bit Index
Explicit Replication (BIER) architecture and how it supports Explicit Replication (BIER) architecture and how it supports
forwarding of multicast data packets. A BIER domain consists of Bit- forwarding of multicast data packets. A BIER domain consists of Bit-
Forwarding Routers (BFRs) that are uniquely identified by their Forwarding Routers (BFRs) that are uniquely identified by their
respective BFR-ids. An ingress border router (acting as a Bit respective BFR-ids. An ingress border router (acting as a Bit
Forwarding Ingress Router (BFIR)) inserts a Forwarding Bit Mask Forwarding Ingress Router (BFIR)) inserts a Forwarding Bit Mask
(F-BM) into a packet. Each targeted egress node (referred to as a (F-BM) into a packet. Each targeted egress node (referred to as a
Bit Forwarding Egress Router (BFER)) is represented by Bit Mask Bit Forwarding Egress Router (BFER)) is represented by Bit Mask
Position (BMP) in the BMS. A transit or intermediate BIER node, Position (BMP) in the BMS. A transit or intermediate BIER node,
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Problem Statement 2. Problem Statement
[I-D.ietf-bier-oam-requirements] sets forth the requirement to define [I-D.ietf-bier-oam-requirements] sets forth the requirement to define
PMTUD protocol for BIER domain. This document describes the PMTUD protocol for BIER domain. This document describes the
extension to [I-D.kumarzheng-bier-ping] for use in BIER PMTUD extension to [I-D.ietf-bier-ping] for use in BIER PMTUD solution.
solution.
Current PMTUD mechanisms [RFC1191], [RFC1981], and [RFC4821] are Current PMTUD mechanisms ([RFC1191], [RFC1981], and [RFC4821]) are
primarily targeted to work on point-to-point, i.e. unicast paths. primarily targeted to work on point-to-point, i.e. unicast paths.
These mechanisms use packet fragmentation control by disabling These mechanisms use packet fragmentation control by disabling
fragmentation of the probe packet. As result, a transient node that fragmentation of the probe packet. As a result, a transient node
cannot forward a probe packet that is bigger than its link MTU sends that cannot forward a probe packet that is bigger than its link MTU
to the ingress node an error notification, otherwise the egress sends to the packet source an error notification, otherwise the
responds with a positive acknowledgement. Thus, through series of packet destination may respond with a positive acknowledgement.
iterations, decreasing and increasing size of the probe packet, the Thus, possibly through a series of iterations, varying the size of
ingress node discovers the MTU of the particular path. the probe packet, the packet source discovers the PMTU of the
particular path.
Thus applied such existing PMTUD solutions are inefficient for point- Thus applied such existing PMTUD solutions are inefficient for point-
to-multipoint paths constructed for multicast traffic. Probe packets to-multipoint paths constructed for multicast traffic. Probe packets
must be flooded through the whole set of multicast distribution paths must be flooded through the whole set of multicast distribution paths
over and over again until the very last egress responds with a over and over again until the very last egress responds with a
positive acknowledgement. Consider without loss of generality an positive acknowledgement. Consider without loss of generality an
example multicast network presented in Figure 1, where MTU on all example multicast network presented in Figure 1, where MTU on all
links but one (B,D) is the same. If MTU on link (B,D) is smaller links but one (B,D) is the same. If MTU on link (B,D) is smaller
than the MTU on the other links, using existing PMTUD mechanism than the MTU on the other links, using existing PMTUD mechanism
probes will unnecessary flood to leaf nodes E, F, and G for the probes will unnecessary flood to leaf nodes E, F, and G for the
skipping to change at page 4, line 34 skipping to change at page 4, line 34
--| C |-- --| C |--
----- \ ----- ----- \ -----
--| G | --| G |
----- -----
Figure 1: Multicast network Figure 1: Multicast network
3. PMTUD Mechanism for BIER 3. PMTUD Mechanism for BIER
A BFIR selects a set of BFERs for the specific multicast A BFIR selects a set of BFERs for the specific multicast
distribution. Such BFIR determines, by explicitly controlling subset distribution. Such a BFIR determines, by explicitly controlling
of targeted BFERs and transmitting series of probe packets, the MTU subset of targeted BFERs and transmitting series of probe packets,
of that multicast distribution path. The critical step is that in the MTU of that multicast distribution tree. The critical step is
case of failure at an intermediate BFR to forward towards the subset that in case of failure at an intermediate BFR to forward towards the
of targeted downstream BFERs, the BFR responds with a partial subset of targeted downstream BFERs, the BFR responds with a partial
(compared to the one it received in the request) bitmask towards the (compared to the one it received in the request) bitmask towards the
originating BFIR in error notification. That allows for originating BFIR in error notification. That allows for
retransmission of the next probe with smaller MTU address only retransmission of the next probe with smaller MTU address only
towards the failed downstream BFERs instead of all BFERs addressed in towards the failed downstream BFERs instead of all BFERs addressed in
the previous probe. In the scenario discussed in Section 2 the the previous probe. In the scenario discussed in Section 2 the
second and all following (if needed) probes will be sent only to the second and all following (if needed) probes will be sent only to the
node D since MTU discovery of E, F, and G has been completed already node D since MTU discovery of E, F, and G has been completed already
by the first probe successfully. by the first probe successfully.
[I-D.kumarzheng-bier-ping] introduced BIER Ping as transport- [I-D.ietf-bier-ping] introduced BIER Ping as a transport-independent
independent OAM mechanism to detect and localize failures in BIER OAM mechanism to detect and localize failures in the BIER data plane.
data plane. This document specifies how BIER Ping can be used to
perform efficient PMTUD in BIER domain.
Consider network displayed in Figure 1 to be presentation of a BIER This document specifies how BIER Ping can be used to perform
domain and all nodes to be BFRs. To discover MTU over BIER domain to efficient PMTUD in the BIER domain.
BFERs D, F, E, and G BFIR A will use BIER Ping with Data TLV, defined
in Section 3.1. Size of the first probe set to _M_max_ determined as
minimal MTU value of BFIR's links to BIER domain. As been assumed in
Section 2, MTUs of all links but link (B,D) are the same. Thus BFERs
E. F, and G would receive BIER Echo Request and will send their
respective replies to BFIR A. BFR B may pass the packet which is too
large to forward over egress link (B, D) to the appropriate network
layer for error processing where it would be recognized as BIER Echo
Request packet. BFR B MUST send BIER Echo Reply to BFIR A and MUST
include Downstream Mapping TLV, defined in [I-D.kumarzheng-bier-ping]
setting its fields in the following fashion:
o MTU SHOULD be set to minimal MTU value among all egress BIER links Consider the network displayed in Figure 1 to be presentation of a
that could be used to reach B's downstream BFERs; BIER domain and all nodes to be BFRs. To discover MTU over BIER
domain to BFERs D, F, E, and G BFIR A will use BIER Ping with Data
TLV, defined in Section 3.1. Size of the first probe set to M_max
determined as minimal MTU value of BFIR's links to BIER domain. As
has been assumed in Section 2, MTUs of all links but link (B,D) are
the same. Thus BFERs E. F, and G would receive BIER Echo Request
and will send their respective replies to BFIR A. BFR B may pass the
packet which is too large to forward over egress link (B, D) to the
appropriate network layer for error processing where it would be
recognized as a BIER Echo Request packet. BFR B MUST send BIER Echo
Reply to BFIR A and MUST include Downstream Mapping TLV, defined in
[I-D.ietf-bier-ping] setting its fields in the following fashion:
o MTU SHOULD be set to the minimal MTU value among all egress BIER
links, logical links between this and downstream BFRs, that could
be used to reach B's downstream BFERs;
o Address Type MUST be set to 0 [Ed.note: we need to define 0 as o Address Type MUST be set to 0 [Ed.note: we need to define 0 as
valid value for the Address Type field with the specific semantics valid value for the Address Type field with the specific semantics
to "Ignore" it.] to "Ignore" it.]
o I flag MUST be cleared; o I flag MUST be cleared;
o Downstream Interface Address field (4 octets) MUST be zeroed and o Downstream Interface Address field (4 octets) MUST be zeroed and
MUST include in Egress Bitstring sub-TLV the list of all BFERs MUST include in the Egress Bitstring sub-TLV the list of all BFERs
that cannot be reached because the attempted MTU turned out to be that cannot be reached because the attempted MTU turned out to be
too small. too small.
The BFIR will receive either of the two types of packets: The BFIR will receive either of the two types of packets:
o a positive Echo Reply from one of BFERs to which the probe has o a positive Echo Reply from one of BFERs to which the probe has
been sent. In such case the bit corresponding to the BFER MUST be been sent. In this case the bit corresponding to the BFER MUST be
cleared from the BMS; cleared from the BMS;
o a negative Echo Reply with bit string listing unreached BFERs and o a negative Echo Reply with bit string listing unreached BFERs and
recommended MTU value MTU". The BFIR MUST add the bit string to recommended MTU value MTU'. The BFIR MUST add the bit string to
its BMS and set size of the next probe as min(MTU, MTU") its BMS and set size of the next probe as min(MTU, MTU')
If upon expiration of the Echo Request timer BFIR didn't receive any If upon expiration of the Echo Request timer BFIR didn't receive any
Echo Replies, then the size of the probe SHOULD be decreased. There Echo Replies, then the size of the probe SHOULD be decreased. There
are scenarios when an implementation of the PMTUD would not decrease are scenarios when an implementation of the PMTUD would not decrease
the size of the probe. For example, if upon expiration of the Echo the size of the probe. For example, if upon expiration of the Echo
Request timer BFIR didn't receive any Echo Reply, then BFIR MAY Request timer BFIR didn't receive any Echo Reply, then BFIR MAY
continue to retransmit the probe using the initial size and MAY apply continue to retransmit the probe using the initial size and MAY apply
probe delay retransmission procedures. The algorithm used to delay probe delay retransmission procedures. The algorithm used to delay
retransmission procedures on BFIR is outside the scope of this retransmission procedures on BFIR is outside the scope of this
specification. The BFIR MUST continue sending probes using BMS until specification. The BFIR sends probes using BMS and locally defiined
the bit string is clear or the discovery is declared unsuccessful. retransmission procedures until either the bit string is clear, i.e.
In case of convergence of the procedure, the size of the last probe contains no set bits, or until the BFIR retransmission procedure
indicates the MTU size that can be used for all BFERs in the initial terminates and PMTU discovery is declared unsuccessful. In case of
BMS without incurring fragmentation. convergence of the procedure, the size of the last probe indicates
the PMTU size that can be used for all BFERs in the initial BMS
without incurring fragmentation.
Thus we conclude that in order to comply with the requirement in Thus we conclude that in order to comply with the requirement in
[I-D.ietf-bier-oam-requirements]: [I-D.ietf-bier-oam-requirements]:
o a BFR SHOULD support PMTUD; o a BFR SHOULD support PMTUD;
o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU o a BFR MAY use defined per BIER sub-domain MTU value as initial MTU
value for discovery or use it as MTU for this BIER sub-domain to value for discovery or use it as MTU for this BIER sub-domain to
reach BFERs. reach BFERs;
o a BFIR MUST have a locally defined of PMTUD probe retransmission
procedure.
3.1. Data TLV for BIER Ping 3.1. Data TLV for BIER Ping
There need to be control of probe size in order to support the BIER There needs to be a control for probe size in order to support the
PMTUD. Data TLV format is presented in Figure 2. BIER PMTUD. Data TLV format is presented in Figure 2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBA1) | Length | | Type (TBA1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | | Data |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 16 skipping to change at page 7, line 21
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------+---------------+ +-------+-------------+---------------+
| TBA1 | Data | This document | | TBA1 | Data | This document |
+-------+-------------+---------------+ +-------+-------------+---------------+
Table 1: Data TLV Type Table 1: Data TLV Type
5. Security Considerations 5. Security Considerations
Routers that support PMTUD based on this document are subject to the Routers that support PMTUD based on this document are subject to the
same security considerations as defined in [I-D.kumarzheng-bier-ping] same security considerations as defined in [I-D.ietf-bier-ping]
6. Acknowledgement 6. Acknowledgement
TBD Authors greatly appreciate thorough review and the most detailed
comments by Eric Gray.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-03 (work in Replication", draft-ietf-bier-architecture-05 (work in
progress), January 2016. progress), October 2016.
[I-D.kumarzheng-bier-ping] [I-D.ietf-bier-ping]
Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
and G. Mirsky, "BIER Ping and Trace", draft-kumarzheng- and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier-
bier-ping-02 (work in progress), December 2015. ping-00 (work in progress), July 2016.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 8, line 12 skipping to change at page 8, line 21
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <http://www.rfc-editor.org/info/rfc4821>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-bier-oam-requirements] [I-D.ietf-bier-oam-requirements]
Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N.,
Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S. Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S.
Pallagatti, "Operations, Administration and Maintenance Pallagatti, "Operations, Administration and Maintenance
(OAM) Requirements for Bit Index Explicit Replication (OAM) Requirements for Bit Index Explicit Replication
(BIER) Layer", draft-ietf-bier-oam-requirements-01 (work (BIER) Layer", draft-ietf-bier-oam-requirements-03 (work
in progress), March 2016. in progress), January 2017.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson ZTE Corp.
Email: gregory.mirsky@ericsson.com Email: gregimirsky@gmail.com
Tony Przygienda Tony Przygienda
Juniper Networks Juniper Networks
Email: prz@juniper.net Email: prz@juniper.net
Andrew Dolganow Andrew Dolganow
Nokia Nokia
Email: andrew.dolganow@nokia.com Email: andrew.dolganow@nokia.com
 End of changes. 29 change blocks. 
75 lines changed or deleted 84 lines changed or added

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