draft-ietf-bmwg-mpls-forwarding-meth-00.txt   draft-ietf-bmwg-mpls-forwarding-meth-01.txt 
Network Working Group Aamer Akhter Network Working Group Aamer Akhter
Internet Draft Rajiv Asati Internet Draft Cisco Systems
Intended status: Informational Cisco Systems Intended status: Informational
September 15, 2008 Expires: May 2009 Rajiv Asati
Cisco Systems
November 3, 2008
MPLS Forwarding Benchmarking Methodology MPLS Forwarding Benchmarking Methodology
draft-ietf-bmwg-mpls-forwarding-meth-00.txt draft-ietf-bmwg-mpls-forwarding-meth-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 34 skipping to change at page 1, line 37
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 15, 2009. This Internet-Draft will expire on May 3, 2009.
Abstract Abstract
The purpose of this draft is to describe a methodology specific to This document describes a methodology specific to the benchmarking
the benchmarking of MPLS forwarding devices. The scope of this of MPLS forwarding devices, limited to various types of packet-
benchmarking will be limited to various types of packet-forwarding forwarding and delay measurements. It builds upon the tenets set
and delay measurements. It builds upon the tenets set forth in forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF
RFC2544 [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Benchmarking Methodology Working Group (BMWG) efforts. This
Methodology Working Group (BMWG) efforts. This document seeks to document seeks to extend these efforts to the MPLS paradigm.
extend these efforts to the MPLS paradigm.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Document Scope.................................................3 2. Document Scope.................................................3
3. Key Words to Reflect Requirements..............................3 3. Key Words to Reflect Requirements..............................3
4. Test Methodology...............................................3 4. Test Methodology...............................................3
4.1. Test Considerations..........................................4 4.1. Test Considerations..........................................4
4.1.1. IGP Support................................................4 4.1.1. IGP Support................................................5
4.1.2. Label Distribution Support.................................5 4.1.2. Label Distribution Support.................................5
4.1.3. Frame Sizes................................................5 4.1.3. Frame Sizes................................................5
4.1.4. TTL or Hop Count...........................................5 4.1.4. Time-to-Live (TTL) or Hop Limit............................6
4.1.5. Trial Duration.............................................6 4.1.5. Trial Duration.............................................6
4.1.6. Address Resolution and Dynamic Protocol State..............6 4.1.6. Address Resolution and Dynamic Protocol State..............7
4.1.7. Abbreviations Used.........................................7 4.1.7. Abbreviations Used.........................................7
5. Reporting Format...............................................7 5. Reporting Format...............................................7
6. MPLS Forwarding Benchmarking tests.............................8 6. MPLS Forwarding Benchmarking Tests.............................8
6.1. Throughput...................................................9 6.1. Throughput..................................................11
6.1.1. Throughput for MPLS Label Imposition.......................9 6.1.1. Throughput for MPLS Label Imposition......................11
6.1.2. Throughout for MPLS Label Swap............................10 6.1.2. Throughout for MPLS Label Swap............................12
6.1.3. Throughout for MPLS Label Disposition.....................11 6.1.3. Throughout for MPLS Label Disposition.....................13
6.1.4. Throughput for MPLS Label Disposition (Aggregate).........12 6.1.4. Throughput for MPLS Label Disposition (Aggregate).........14
6.2. Latency Measurement.........................................13 6.2. Latency Measurement.........................................15
6.3. Frame Loss Rate Measurement (FLR)...........................15 6.3. Frame Loss Rate Measurement (FLR)...........................15
6.4. System Recovery.............................................16 6.4. System Recovery.............................................16
6.5. Reset.......................................................17 6.5. Reset.......................................................17
7. Security Considerations.......................................18 7. Security Considerations.......................................18
8. IANA Considerations...........................................18 8. IANA Considerations...........................................18
9. References....................................................19 9. Acknowledgement...............................................18
9.1. Normative References........................................19 10. References...................................................19
9.2. Informative References......................................19 10.1. Normative References.......................................19
10.2. Informative References.....................................19
Author's Addresses...............................................20 Author's Addresses...............................................20
Intellectual Property Statement..................................20 Intellectual Property Statement..................................20
Disclaimer of Validity...........................................21 Disclaimer of Validity...........................................21
Copyright Statement..............................................21 Copyright Statement..............................................21
Acknowledgment...................................................21
1. Introduction 1. Introduction
Over the past several years MPLS networks have gained greater Over the past several years MPLS networks have gained greater
popularity. However, there is no standard method to compare and popularity. However, there is no standard method to compare and
contrast the varying implementations and their strong and weak contrast the varying implementations and their strong and weak
points. This document proposes a methodology using common criteria points. This document proposes a methodology using common criteria
for the comparison of various implementations of basic MPLS for the comparison of various implementations of basic MPLS
forwarding devices. forwarding devices.
The terms used in this document remain consistent with those defined The terms used in this document remain consistent with those defined
in "Benchmarking Terminology for Network Interconnect Devices" in "Benchmarking Terminology for Network Interconnect Devices"
RFC1242 [RFC1242]. This terminology SHOULD be consulted before using RFC1242 [RFC1242]. This terminology SHOULD be consulted before using
or applying the recommendations of this document. or applying the recommendations of this document.
2. Document Scope 2. Document Scope
The purpose of this draft is to describe a methodology specific to
the benchmarking of MPLS forwarding devices. The scope of this
benchmarking will be limited to various types of packet-forwarding
and delay measurements in a laboratory setting. It builds upon the
tenets set forth in RFC2544 [RFC2544], RFC1242 [RFC1242] and other
IETF Benchmarking Methodology Working Group (BMWG) efforts.
MPLS [RFC3031] is a foundation enabling technology for other more MPLS [RFC3031] is a foundation enabling technology for other more
advanced technologies such as Layer 3 MPLS-VPNs, Layer 2 MPLS-VPNs, advanced technologies such as Layer 3 MPLS-VPNs, Layer 2 MPLS-VPNs,
and MPLS Traffic Engineering. This document focuses on MPLS and MPLS Traffic Engineering. This document focuses on MPLS
forwarding characterization. forwarding characterization. This document is not a replacement for,
but a complement to, RFC 2544.
3. Key Words to Reflect Requirements 3. Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. RFC 2119 defines the use of these key words to help make [RFC2119]. RFC 2119 defines the use of these key words to help make
the intent of standards track documents as clear as possible. While the intent of standards track documents as clear as possible. While
this document uses these keywords, this document is not a standards this document uses these keywords, this document is not a standards
track document. track document.
skipping to change at page 4, line 22 skipping to change at page 4, line 27
| Port A2 +-----+ DA2 DB2 +-----+ Port B2 | | Port A2 +-----+ DA2 DB2 +-----+ Port B2 |
+---------+ | | +---------+ +---------+ | | +---------+
... | | ... ... | | ...
+---------+ | | +---------+ +---------+ | | +---------+
| Test | +-----------------+ | Test | | Test | +-----------------+ | Test |
| Port Ap | | Port Bp | | Port Ap | | Port Bp |
+---------+ +---------+ +---------+ +---------+
Figure 1 Topology #1 for MPLS Forwarding Benchmarking Figure 1 Topology #1 for MPLS Forwarding Benchmarking
Where number of ports (p) is determined by the maximum p = number of ports; determined by the maximum unidirectional
unidirectional forwarding throughput of the DUT and the load forwarding throughput of the DUT and the load capacity of the media
capacity of the media between the Test Ports and DUT. For example, between the Test Ports and DUT.
if the DUT's forwarding throughput is 100 frames per second (fps),
and the media capacity is 50 fps, then p = 2. For example, if the DUT's forwarding throughput is 100 frames per
second (fps), and the media capacity is 50 fps, then p = 2.
The exact throughput is a measured quantity obtained through
testing. Throughput may vary depending on the number of ports used,
and other factors. The number of ports used (p) SHOULD be reported
for both Tx and Rx sides of DUT. Please see Test Setup in section 6.
4.1. Test Considerations 4.1. Test Considerations
This methodology assumes a full-duplex uniform medium topology. The This methodology assumes a full-duplex uniform medium topology. The
medium used MUST be reported in each test result. Issues regarding medium used MUST be reported in each test result. Issues regarding
mixed transmission media, speed mismatches, media header differences mixed transmission media, speed mismatches, media header differences
etc, are not under consideration. Traffic-affecting features such as etc, are not under consideration. Traffic-affecting features such as
Flow control, QoS, Graceful Restart etc. MUST be disabled, unless Flow control, QoS, Graceful Restart etc. MUST be disabled, unless
explicitly requested by the test case. Additionally, any non- explicitly requested in the test case. Additionally, any non-
essential traffic MUST also be avoided. essential traffic MUST also be avoided.
4.1.1. IGP Support 4.1.1. IGP Support
It is highly RECOMMENDED that all of the interfaces (A1, DA1, DB1, It is highly RECOMMENDED that all of the interfaces (A1, DA1, DB1,
A2..) on DUT and test tool support an IGP such as IS-IS, OSPF, A2..) on DUT and test tool support an IGP such as IS-IS, OSPF,
EIGRP, RIP etc. Furthermore, there are testing considerations in EIGRP, RIP etc. Furthermore, there are testing considerations in
this document that the device is able to provide a stable control- this document that the device is able to provide a stable control-
plane during heavy forwarding workloads. The route distribution plane during heavy forwarding workloads. The route distribution
method used (OSPF, IS-IS, EIGRP, RIP etc.) MUST be reported. method used (OSPF, IS-IS, EIGRP, RIP etc.) MUST be reported.
4.1.2. Label Distribution Support 4.1.2. Label Distribution Support
The DUT and test tool must support at least one protocol for The DUT and test tool must support at least one protocol for
exchanging MPLS labels. The DUT and test tool MUST be capable of exchanging MPLS labels. The DUT and test tool MUST be capable of
learning and advertising MPLS label bindings via the chosen learning and advertising MPLS label bindings via the chosen
protocol(s), and use them during packet forwarding all the time protocol(s), and use them during packet forwarding all the time
(includes when the label bindings change). The most commonly used (including when the label bindings change). The most commonly used
protocol is Label Distribution Protocol (LDP) [RFC5036], RSVP-TE protocols are Label Distribution Protocol (LDP) [RFC5036], Resource
[RFC5151] and MP-BGP [RFC4364]. Reservation Protocol-Traffic Engineering (RSVP-TE) [RFC5151] and
Border Gateway Protocol (BGP) [RFC3107].
All of the interfaces connected to the DUT such as A1, DA1, DB1, A2 All of the interfaces connected to the DUT such as A1, DA1, DB1, A2
etc., SHOULD support Label Distribution Protocol (LDP), RSVP-TE, and etc., SHOULD support LDP, RSVP-TE, and BGP for IPv4 or IPv6
MP-BGP for IPv4 or IPv6 FECs. Forwarding Equivalence Classes (FECs).
This draft discourages the use of static label to establish the MPLS This document discourages the use of static label to establish the
label switched paths, since it is not commonly used in the MPLS label switched paths, since it is not commonly used in the
production networks. production networks.
4.1.3. Frame Sizes 4.1.3. Frame Sizes
Each test SHOULD be run with different frame sizes in different Each test SHOULD be run with different (layer 2) frame sizes in
trials. For better reference, the recommended sizes are 64, 128, different trials. The recommended sizes for IPv4 are 64, 128, 256,
256, 512, 1024, 1280 and 1518 for IPv4. Recommended sizes for other 512, 1024, 1280 and 1518. Recommended sizes for other media can be
media can be found in RFC 2544 and IPv6 Benchmarking [RFC5180]. found in RFC 2544 and IPv6 Benchmarking [RFC5180]. Frame sizes MUST
Frame sizes MUST be based on the pre-MPLS shim version of the frame. be based on the pre-MPLS shim version of the frame.
In addition to the individual frame size trials, an IMIX traffic run In addition to the individual frame size trials, results MAY also be
MAY also be included. collected with multiple simultaneous frame sizes (sometimes referred
to as an IMIX to simulate real network traffic according to the
frame size ordering and usage). There is no standard for mixtures of
frame sizes, and the results are subject to wide interpretation. See
section 18 of RFC 2544.
When running trials between different frame sizes, the DUT When running trials using multiple simultaneous frame sizes, the DUT
configuration MUST remain the same. configuration MUST remain the same.
4.1.4. TTL or Hop Count 4.1.4. Time-to-Live (TTL) or Hop Limit
The MPLS TTL or IPv4 TTL or IPv6 Hop Count (depending on which The MPLS TTL or IPv4 TTL or IPv6 Hop Limit (depending on which
portion of the packet the DUT is basing the forwarding behavior) portion of the frame the DUT is basing the forwarding behavior) MUST
MUST be large enough to traverse the DUT. be large enough to traverse the DUT.
If TTL/Hop Limit Decrement is a configurable option on the DUT, the
setting SHOULD be reported.
4.1.5. Trial Duration 4.1.5. Trial Duration
Unless otherwise specified, the test portion of each trial SHOULD be Unless otherwise specified, the test portion of each trial SHOULD be
no less than 30 seconds when static routing is in place and no less no less than 30 seconds when static routing is in place, and no less
than 200 seconds when a dynamic routing protocol and LDP (default than 200 seconds when a dynamic routing protocol and LDP (default
holddown timer is 180 seconds) are being used. LDP holddown timer is 180 seconds) are being used.
The longer trial time for when dynamic routing protocols are being The longer trial time used for dynamic routing protocols is to
used is for verifying that the DUT is able to maintain a stable verify that the DUT is able to maintain a stable control plane when
control plane when the data-forwarding plane is under stress. the data-forwarding plane is under stress.
4.1.5.1. Traffic Verification 4.1.5.1. Traffic Verification
In all cases the sent traffic MUST be accounted for, whether it was In all cases, sent traffic MUST be accounted for, whether it was
received on the wrong port, correct port or not received at all. received on the wrong port, correct port or not received at all.
Specifically, traffic loss (also referred to as frame loss) is Specifically, traffic loss (also referred to as frame loss) is
defined as the traffic (i.e. one or more frames) not received where defined as the traffic (i.e. one or more frames) not received where
expected (i.e. received on incorrect port, or received with expected (i.e. received on incorrect port, or received with
incorrect layer2 or above header information etc.). In addition, the incorrect layer2 or above header information etc.). In addition,
MPLS header presence or non-presence of the packet MUST be verified, presence or absence of MPLS header, ethertype (0x8847 vs. 0x0800),
as well as checksum, frame sequencing and correct MPLS TTL checksum, frame sequencing and correct MPLS TTL decrementing, MUST
decrementing. be verified in the received frame.
The MPLS header presence will be determined by the test. Some tests
will require the MPLS header to be imposed while others will require
a swap or disposition. In general, many test tools will by default
only verify that they have received the embedded signature on the
receive side, but will not validate MPLS stack depth. An even
greater level of verification would be to check if the correct label
was imposed, but that is considered out of scope for these tests.
"In all cases the sent traffic MUST be accounted for, whether it was Many test tools may, by default, only verify that they have received
received on the wrong port, correct port or not received at all. In the embedded signature on the receive side. However, for MPLS header
addition, the MPLS header...." presence verification, some tests will require the MPLS header to be
imposed while others will require a swap or disposition. Hence, this
document requires the test tool to verify the MPLS stack depth. An
even greater level of verification would be to check if the correct
label was imposed, but that is out of scope for these tests.
4.1.6. Address Resolution and Dynamic Protocol State 4.1.6. Address Resolution and Dynamic Protocol State
If the test or media is making use of a dynamic protocol (eg ARP, If the test or media is making use of a dynamic protocol (eg ARP,
OSPF, LDP), all state for the protocols should be pre-established OSPF, LDP), all state for the protocols should be pre-established
before the start of the trial. before the start of the trial.
4.1.7. Abbreviations Used 4.1.7. Abbreviations Used
Please refer to Figure 1, "Port based Remote Network" for a topology Please refer to Figure 1, "Port based Remote Network" for a topology
view of the network. The following abbreviations are used in this view of the network. The following abbreviations are used in this
document - document -
M := Module Side (could be A or B) M := Module Side (could be A or B)
P := port number P := port number
RN := Remote Network (can also be thought of as a network that is RN := Remote Network (can also be thought of as a network that is
reachable via) Mp. reachable via Mp).
Y := number of network. (ie the first network reachable via B1 Y := number of network. (i.e. the first network reachable via B1
would be called B1RN1 and the 5th network would be called B1RN5) would be called B1RN1 and the 5th network would be called B1RN5)
5. Reporting Format 5. Reporting Format
For each test case, it is recommended that the following variables For each test case, it is RECOMMENDED that the following variables
be reported in addition to the specific parameters requested by the be reported in addition to the specific parameters requested by the
test case: test case:
Parameter Unit Parameter Units or Examples
Internet Protocol IPv4, IPv6, Dual-Stack Internet Protocol IPv4, IPv6, Dual-Stack
Label Distribution Protocol LDP, RSVP-TE, BGP (or Label Distribution Protocol LDP, RSVP-TE, BGP (or
combinations) combinations)
MPLS Forwarding Operation Imposition, Swap, MPLS Forwarding Operation Imposition, Swap,
Disposition Disposition
IGP ISIS, OSPF, EIGRP, RIP, IGP ISIS, OSPF, EIGRP, RIP,
static, etc. static.
Throughput Frames per second Throughput Frames per second
Interface Type GigE, POS, ATM etc Interface Type GigE, POS, ATM etc
Interface Speed 1 gbps, 100 Mbps, etc Interface Speed 1 gbps, 100 Mbps, etc
Interface Encapsulation VLAN, PPP, HDLC Interface Encapsulation VLAN, PPP, HDLC
Packet Size Bytes
Frame Size Bytes
Number of A and B 1A, 2B Number of A and B 1A, 2B
interfaces (see Figure 1) interfaces (see Figure 1)
The individual test cases may have additional reporting requirements The individual test cases may have additional reporting requirements
that may refer to other RFCs. that may refer to other RFCs.
6. MPLS Forwarding Benchmarking tests 6. MPLS Forwarding Benchmarking Tests
MPLS is altogether a different forwarding paradigm from IP. Unlike MPLS is a different forwarding paradigm from IP. Unlike IP packet
IP packet and IP forwarding, MPLS packet is likely to contain more and IP forwarding, an MPLS packet may contain more than one MPLS
than one MPLS headers and may go through one of three forwarding header and may go through one of three forwarding operations -
operations - imposition, swap and disposition. Such characteristics imposition, swap and disposition. Such characteristics desire
desire further granularity in MPLS forwarding benchmarking than further granularity in MPLS forwarding benchmarking than those
those of described in RFC2544. Thus the benchmarking includes, but described in RFC2544. Thus the benchmarking includes, but is not
not limited to: limited to:
1. Throughput 1. Throughput
2. Latency 2. Latency
3. Frame Loss rate 3. Frame Loss rate
4. System Recovery 4. System Recovery
5. Reset 5. Reset
6. MPLS EXP field Operations (including explicit-null cases) 6. MPLS EXP field Operations (including explicit-null cases)
7. Negative Scenarios (TTL expiry, etc) 7. Negative Scenarios (TTL expiry, etc)
skipping to change at page 8, line 38 skipping to change at page 9, line 16
4. System Recovery 4. System Recovery
5. Reset 5. Reset
6. MPLS EXP field Operations (including explicit-null cases) 6. MPLS EXP field Operations (including explicit-null cases)
7. Negative Scenarios (TTL expiry, etc) 7. Negative Scenarios (TTL expiry, etc)
8. Multicast 8. Multicast
This document focuses on the first five categories. All the This document focuses on the first five categories, inline with the
benchmarking test cases described in this document are expected to spirit of RFC2544. All the benchmarking test cases described in this
at a minimum follow the below 'Test Setup' and 'Test Procedure.' document are expected to, at a minimum, follow the 'Test Setup' and
'Test Procedure' below -
Test Setup Test Setup
It is recommended that a single A and B interface SHOULD be used.
However, if the forwarding throughput of the DUT is more than that
of the media rate of a single interface, then additional A and B
interfaces MUST be enabled so as to exceed the DUT's forwarding
throughput. In such case, the tool traffic should use BpRN1 and
BpAN as the IP destinations in a weighted round robin fashion. The
weighting ratio between BpRN1 and BpAN is a constant test
parameter. A suggested ratio is 1:100 with BpAN:BpRN1. The traffic
streams offered MUST conform to section 16 of RFC 2544.
Test Procedure Referring to Figure 1, a single A and B interface SHOULD be used
(p = 1 SHOULD be used). However, if the forwarding throughput of
the DUT is more than that of the media rate of a single interface,
then additional A and B interfaces MUST be enabled so as to exceed
the DUT's forwarding throughput. In such case, the tool traffic
should use IP addresses assigned to BpRN1 and BpAN as the IP
destinations and conform to section 16 of RFC 2544.
Send traffic from port Ap towards DUT at a constant load towards Test Procedure (Refer to section 26 of RFC 2544)
IP prefixes (BpRN1 addresses) advertised by the tool on the
receive ports, for a fixed duration of time. Send traffic from port(s) Ap towards DUT at a constant load
towards IP prefixes (BpRN1 addresses) advertised by the tool on
the receive ports, for a fixed time interval.
If any frame loss is detected, a new iteration is needed where the If any frame loss is detected, a new iteration is needed where the
offered load is decreased and the sender will transmit again. An offered load is decreased and the sender will transmit again. An
iterative search algorithm MUST be used to determine the maximum iterative search algorithm MUST be used to determine the maximum
offered frame rate with a zero frame loss. offered frame rate with a zero frame loss.
Each iteration will involve varying the offered load of the Each iteration should involve varying the offered load of the
regular traffic, while keeping the other parameters (test traffic, while keeping the other parameters (test duration, number
duration, number of interfaces, number of addresses, frame size of interfaces, number of addresses, frame size etc) constant,
etc) constant, until the maximum rate at which none of the offered until the maximum rate at which none of the offered frames are
frames are dropped is determined. dropped is determined.
6.1. Throughput 6.1. Throughput
This section contains the description of the tests that are related This section contains the description of the tests that are related
to the characterization of DUT's MPLS frame forwarding. to the characterization of DUT's MPLS traffic forwarding.
6.1.1. Throughput for MPLS Label Imposition 6.1.1. Throughput for MPLS Label Imposition
Objective Objective
To obtain the maximum forwarding rate during label imposition To obtain the DUT's Throughput (as per RFC 2544) during label
(i.e. IP to MPLS) for a regular (IPv4 or IPv6) packet by the DUT. imposition (i.e. IP to MPLS).
Test Setup Test Setup
In addition to setup described in section 6, the test tool should In addition to setup described in section 6, the test tool should
advertise the IP prefix(es) i.e. RNx(using a routing protocol as advertise the IP prefix(es) i.e. RNx(using a routing protocol as
per section 1.1) and associated MPLS label (using a label per section 1.1) and associated MPLS label (using a label
distribution protocol as per section 1.2) on its receive ports Bp distribution protocol as per section 1.2) on its receive ports Bp
to DUT. The test tool may learn these IP prefixes on it's transmit to DUT. The test tool may learn these IP prefixes on its transmit
ports Ap from DUT. ports Ap from DUT.
Discussion Discussion
The DUT's MPLS forwarding table must contain non-reserved MPLS The DUT's MPLS forwarding table must contain a non-reserved MPLS
label value as the outgoing label for the learned prefix, label value as the outgoing label for the learned prefix,
resulting in IP-to-MPLS forwarding operation. The testool must resulting in IP-to-MPLS forwarding operation. The test tool must
receive MPLS packets on receive ports Bp (from DUT) with the same receive MPLS packets on receive ports Bp (from DUT) with the same
label values that are advertised. label values that are advertised.
Procedure Procedure
Please see Test Procedure in section 6. Additionally, the test Please see Test Procedure in section 6. Additionally, the test
tool must send unlabeled IP packets on transmit ports Ap (with IP tool MUST send unlabeled IP packets on transmit ports Ap (with IP
destination belonging to above IP prefix(es)), and expect to destination belonging to above IP prefix(es)), and expect to
receive MPLS packets on receive ports Bp. receive MPLS packets on receive ports Bp.
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
Results for each test SHOULD be in the form of a table with a row Results for each test SHOULD be in the form of a table with a row
for each of the tested frame sizes. Additional columns SHOULD for each of the tested frame sizes. Additional columns SHOULD
include: offered load and measured throughput. include: offered load and measured throughput.
6.1.2. Throughout for MPLS Label Swap 6.1.2. Throughout for MPLS Label Swap
Objective Objective
To obtain the maximum label swap rate for a labeled packet (i.e. To obtain the DUT's Throughput (as per RFC 2544) during label
MPLS to MPLS) by the DUT. swapping (i.e. MPLS to MPLS).
Test Setup Test Setup
In addition to setup described in section 6, the test tool must be In addition to setup described in section 6, the test tool must be
set up to advertise IP prefix (using a routing protocol as per set up to advertise IP prefix (using a routing protocol as per
section 1.1) and associated MPLS label (using a label distribution section 1.1) and associated MPLS label (using a label distribution
protocol as per section 1.2) on the receive ports Bp, and learn protocol as per section 1.2) on the receive ports Bp, and learn
the IP prefix(es) with the appropriate MPLS labels on the transmit the IP prefix(es) with the appropriate MPLS labels on the transmit
ports Ap. The test tool then must use the learned MPLS label ports Ap. The test tool then must use the learned MPLS label
values and learned IP prefix values in MPLS packets transmitted on values and learned IP prefix values in MPLS packets transmitted on
ports Ap. ports Ap.
Discussion Discussion
The DUT's MPLS forwarding table must contain non-reserved MPLS The DUT's MPLS forwarding table must contain non-reserved MPLS
label values as the outgoing and incoming labels for the learned label values as the outgoing and incoming labels for the learned
prefix, resulting in MPLS-to-MPLS forwarding operation. The prefix, resulting in MPLS-to-MPLS forwarding operation. The test
testool must receive MPLS packets on receive ports Bp (from DUT). tool must receive MPLS packets on receive ports Bp (from DUT). The
The received MPLS packets must contain the same number of MPLS received MPLS packets must contain the same number of MPLS headers
headers as those of transmitted MPLS Packets. as those of transmitted MPLS Packets.
Procedure Procedure
Please see Test Procedure in section 6. Additionally, the test Please see Test Procedure in section 6. Additionally, the test
tool must send MPLS packets on its transmit ports Ap (with IP tool must send MPLS packets on its transmit ports Ap (with IP
destination belonging to advertised IP prefix(es)), and expect to destination belonging to advertised IP prefix(es)), and expect to
receive MPLS packets on its receive ports Bp. receive MPLS packets on its receive ports Bp.
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
Results for each test SHOULD be in the form of a table with a row Results for each test SHOULD be in the form of a table with a row
for each of the tested frame sizes. Additional columns SHOULD for each of the tested frame sizes.
include: offered load and measured throughput.
6.1.3. Throughout for MPLS Label Disposition 6.1.3. Throughout for MPLS Label Disposition
Objective Objective
To obtain the maximum label disposition rate for MPLS packet (i.e. To obtain the DUT's Throughput (as per RFC 2544) during label
MPLS to IP) by the DUT, when DUT installs ''Untagged'' outgoing disposition (i.e. MPLS to IP) using "Untagged" outgoing label.
label.
Test Setup Test Setup
In addition to setup described in section 6, the test tool must be In addition to setup described in section 6, the test tool must be
set up to advertise the IP prefix(es) (using a routing protocol as set up to advertise the IP prefix(es) (using a routing protocol as
per section 1.1) without any MPLS label on the receive ports Bp, per section 1.1) without any MPLS label on the receive ports Bp,
and learn the IP prefix(es) with the appropriate MPLS labels on and learn the IP prefix(es) with the appropriate MPLS labels on
the transmit ports Ap. The test tool then must use the learned the transmit ports Ap. The test tool then must use the learned
MPLS label values and learned IP prefix values in MPLS packets MPLS label values and learned IP prefix values in MPLS packets
transmitted on ports Ap. transmitted on ports Ap.
Discussion Discussion
The DUT's MPLS forwarding table must contain an untagged outgoing The DUT's MPLS forwarding table must contain an untagged outgoing
label for the learned prefix, resulting in MPLS-to-IP forwarding label for the learned prefix, resulting in MPLS-to-IP forwarding
operation. The testool must receive IP packets on receive ports Bp operation. The test tool must receive IP packets on receive ports
(from DUT). Bp (from DUT).
Procedure Procedure
Please see Test Procedure in section 6. Additionally, the test Please see Test Procedure in section 6. Additionally, the test
tool must send MPLS packets on its transmit ports Ap (with IP tool must send MPLS packets on its transmit ports Ap (with IP
destination belonging to advertised IP prefix(es)), and expect to destination belonging to advertised IP prefix(es)), and expect to
receive IP packets on its receive ports Bp. receive IP packets on its receive ports Bp.
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
Results for each test SHOULD be in the form of a table with a row Results for each test SHOULD be in the form of a table with a row
for each of the tested frame sizes. Additional columns SHOULD for each of the tested frame sizes.
include: offered load and measured throughput.
6.1.4. Throughput for MPLS Label Disposition (Aggregate) 6.1.4. Throughput for MPLS Label Disposition (Aggregate)
Objective Objective
To obtain the maximum label disposition rate for MPLS packet (i.e. To obtain the DUT's Throughput (as per RFC 2544) during label
MPLS to IP) by the DUT, when DUT installs ''Aggregate'' outgoing disposition (i.e. MPLS to IP) using "Aggregate" outgoing label.
label.
Test Setup Test Setup
In addition to setup described in section 6, the DUT should be In addition to setup described in section 6, the DUT should be
provisioned such that it allocates an aggregate outgoing label to provisioned such that it allocates an aggregate outgoing label to
a prefix (where the prefix may be a 'BGP aggregated prefix' , 'BGP a prefix (where the prefix may be a 'BGP aggregated prefix' , 'BGP
VPN connected prefix' or an IGP aggregation that results in an VPN connected prefix' or an IGP aggregation that results in an
aggregate label, etc. and must include the addresses belonging to aggregate label, etc. and must include the addresses belonging to
the DUT receive ports Bp). the DUT receive ports Bp).
The DUT must advertise the IP prefix(es) along with the MPLS The DUT must advertise the IP prefix(es) along with the MPLS
label(s) via a label distribution protocol to the testool on tool label(s) via a label distribution protocol to the test tool on
transmit ports Ap. tool transmit ports Ap.
The test tool then must use the learned MPLS label values and The test tool then must use the learned MPLS label values and
learned IP prefix values in MPLS packets transmitted on ports Ap. learned IP prefix values in MPLS packets transmitted on ports Ap.
Discussion Discussion
The DUT's MPLS forwarding table must contain an aggregate outgoing The DUT's MPLS forwarding table must contain an aggregate outgoing
label and IP forwarding table must contain a valid entry for the label and IP forwarding table must contain a valid entry for the
learned prefix, resulting in MPLS-to-IP forwarding operation (i.e. learned prefix, resulting in MPLS-to-IP forwarding operation (i.e.
MPLS header removal followed by IP lookup). The testool must MPLS header removal followed by IP lookup). The test tool must
receive IP packets on receive ports Bp (from DUT). receive IP packets on receive ports Bp (from DUT).
Procedure Procedure
Please see Test Procedure in section 6. Additionally, the test Please see Test Procedure in section 6. Additionally, the test
tool must send MPLS packets on its transmit ports Ap (with IP tool must send MPLS packets on its transmit ports Ap (with IP
destination belonging to advertised IP prefix(es)), and expect to destination belonging to advertised IP prefix(es)), and expect to
receive IP packets on its receive ports Bp. receive IP packets on its receive ports Bp.
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
Results for each test SHOULD be in the form of a table with a row Results for each test SHOULD be in the form of a table with a row
for each of the tested frame sizes. Additional columns SHOULD for each of the tested frame sizes.
include: offered load and measured throughput.
6.2. Latency Measurement 6.2. Latency Measurement
This measures the time taken by the DUT to forward the MPLS packet This measures the time taken by the DUT to forward the MPLS packet
during various MPLS switching paths such as IP-to-MPLS or MPLS-to- during various MPLS switching paths such as IP-to-MPLS or MPLS-to-
MPLS or MPLS-to-IP involving one or more MPLS headers. MPLS or MPLS-to-IP involving one or more MPLS headers.
The forwarding delay measurement requires the accurate propagation
delay measurement as a prerequisite.
One of the propagation delay measurement mechanisms is to connect
test transmit port such as A1 and test receive port such as B1 with
the wire length=X (bypass DA1 and DB1) and measure the time (t1)
taken by the packet to reach from A1 to B1.
Once the time t1 has been recorded, then the DUT should be inserted
such that the test port A1 connects to DA1 and B1 connects to DB1,
and the sum of A1-DA1 wire length and B1-DB1 wire length equals X.
The packet should be sent from A1 to B1 such that the packet is
received by DA1, which after consulting with its forwarding table,
forwards the packet to B1 via DB1. The time (t2) taken by the packet
to reach B1 (from A1) is recorded.
The difference of time t2-t1 would provide the ballpark measurement
of DUT's forwarding delay.
The measurement for t2 should be performed under each of three
forwarding operations (IP-to-MPLS, MPLS-to-MPLS, MPLS-to-IP) and
measured accordingly.
Objective Objective
To obtain the maximum latency induced by the DUT during MPLS To obtain the maximum latency induced by the DUT during MPLS
packet forwarding for each of three forwarding operations. packet forwarding for each of three forwarding operations.
Test Setup Test Setup
Follow the test setup guidelines established for each of three Follow the Test Setup guidelines established for each of three
MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS),
6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) one by one. 6.1.2 (for MPLS-to-MPLS) ), and 6.1.3 and 6.1.4 (for MPLS-to-IP)
one by one.
Procedure Procedure
Please refer to RFC2544. Additionally, follow the associated Please refer to section 26.2 in RFC2544 in addition to following
procedure for each MPLS forwarding operation - the associated procedure for each MPLS forwarding operation in
accord with the Test Setup described earlier -
IP-to-MPLS forwarding (Imposition) Section 6.1.1 IP-to-MPLS forwarding (Imposition) Section 6.1.1
MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-MPLS forwarding (Swap) Section 6.1.2
MPLS-to-IP forwarding (Disposition) Section 6.1.3 MPLS-to-IP forwarding (Disposition) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
6.3. Frame Loss Rate Measurement (FLR) 6.3. Frame Loss Rate Measurement (FLR)
This measures the percentage of MPLS frames that were not forwarded This measures the percentage of MPLS frames that were not forwarded
during various switching paths such as IP-to-MPLS (imposition) or during various switching paths such as IP-to-MPLS (imposition) or
MPLS-to-IP (swap) or MPLS-IP (disposition) by the DUT under MPLS-to-IP (swap) or MPLS-IP (disposition) by the DUT under
overloaded state. overloaded state.
Please refer to RFC2544 section 26.3 for more details. Please refer to RFC2544 section 26.3 for more details.
Objective Objective
To obtain the frame loss rate, as defined in RFC1242, for each of To obtain the frame loss rate, as defined in RFC1242, for each of
three MPLS forwarding operations of a DUT, throughout the range of three MPLS forwarding operations of a DUT, throughout the range of
input data rates and frame sizes. input data rates and frame sizes.
Test Setup Test Setup
Follow the test setup guidelines established for each of three Follow the Test Setup guidelines established for each of three
MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS),
6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure 6.1.2 (for MPLS-to-MPLS), and 6.1.3 and 6.1.4 (for MPLS-to-IP) and
one by one. procedure one by one.
Procedure Procedure
Please refer to RFC2544. Please refer to section 26.3 of RFC 2544 RFC2544 and follow the
associated procedure for each MPLS forwarding operation one-by-one
Additionally, follow the associated procedure (and test Setup) for in accord with the Test Setup described earlier -
each MPLS forwarding operation one-by-one -
IP-to-MPLS forwarding (Imposition) Section 6.1.1 IP-to-MPLS forwarding (Imposition) Section 6.1.1
MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-MPLS forwarding (Swap) Section 6.1.2
MPLS-to-IP forwarding (Disposition) Section 6.1.3 MPLS-to-IP forwarding (Disposition) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
6.4. System Recovery 6.4. System Recovery
Objective Objective
To characterize the speed at which a DUT recovers from an overload To characterize the speed at which a DUT recovers from an overload
condition. condition.
Test Setup Test Setup
Follow the test setup guidelines established for each of three Follow the Test Setup guidelines established for each of three
MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS),
6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure 6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure
one by one. one by one.
Procedure Procedure
Please refer to RFC2544 section 26.5. Please refer to RFC2544 and follow the associated procedure for
each MPLS forwarding operation in the referenced sections one-by-
one in accord with the Test Setup described earlier -
Additionally, follow the associated procedure (and test Setup) for
each MPLS forwarding operation one-by-one -
IP-to-MPLS forwarding (Imposition) Section 6.1.1 IP-to-MPLS forwarding (Imposition) Section 6.1.1
MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-MPLS forwarding (Swap) Section 6.1.2
MPLS-to-IP forwarding (Disposition) Section 6.1.3 MPLS-to-IP forwarding (Disposition) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4. Same as RFC2544 and the parameters of section 5.
6.5. Reset 6.5. Reset
Objective Objective
To characterize the speed at which a DUT recovers from a device or To characterize the speed at which a DUT recovers from a device or
software reset. software reset.
Test Setup Test Setup
Follow the test setup guidelines established for each of three Follow the Test Setup guidelines established for each of three
MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS), MPLS forwarding operations in section 6.1.1 (for IP-to-MPLS),
6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure 6.1.2 (for MPLS-to-MPLS) and 6.1.3 (for MPLS-to-IP) and procedure
one by one. one by one.
For this test, all graceful-restart features MUST be disabled. For this test, all graceful-restart features MUST be disabled.
Procedure Procedure
Please refer to RFC2544 section 26.5. Examples of hardware and Please refer to RFC2544 section 26.5. Examples of hardware and
software resets are: software resets are:
hardware reset - forwarding module resetting (e.g. OIR). Hardware reset - forwarding module resetting (e.g. OIR).
software reset - reset initiated through a CLI (e.g. reload). Software reset - reset initiated through a CLI (e.g. reload).
Additionally, follow the associated procedure (and test Setup) for Additionally, follow the specific section for procedure (and test
each MPLS forwarding operation one-by-one - Setup) for each MPLS forwarding operation one-by-one -
IP-to-MPLS forwarding (Imposition) Section 6.1.1
IP-to-MPLS forwarding (Imposition) Section 6.1.1
MPLS-to-MPLS forwarding (Swap) Section 6.1.2 MPLS-to-MPLS forwarding (Swap) Section 6.1.2
MPLS-to-IP forwarding (Disposition) Section 6.1.3 MPLS-to-IP forwarding (Disposition) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
Reporting Format Reporting Format
Same as RFC2544, in addition to parameters in Section 4, and the Same as RFC2544 and the parameters of section 5 including the
specific kind of reset performed. specific kind of reset performed.
7. Security Considerations 7. Security Considerations
During the course of test, the test topology must be disconnected Benchmarking activities, as described in this memo, are limited to
from devices that may forward the test traffic into a production technology characterization using controlled stimuli in a laboratory
environment. environment, with dedicated address space and the constraints
specified in the sections above.
The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test
traffic into a production network or misroute traffic to the test
management network.
There are no specific security considerations within the scope of There are no specific security considerations within the scope of
this document. this document.
8. IANA Considerations 8. IANA Considerations
There are no considerations for IANA at this time. There are no considerations for IANA at this time.
9. References 9. Acknowledgement
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen et al., ''Multiprotocol Label Switching The authors would like to thank Mo Khalid, who motivated us to write
Architecture'', Rosen et al., RFC 3031, August 1999. this document. We would like to thank Chip Popoviciu, Jay Karthik,
Rajiv Pap, Samir Vapiwala, Silvija Andrijic Dry, Scott Bradner, Al
Morton and Bill Cerveny for their careful review and suggestions.
[RFC4364] Rosen, E. and Rekhter, Y., ''BGP/MPLS IP Virtual Private 10. References
Networks (VPNs)'', RFC 4364, February 2006.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 10.1. Normative References
B. Thomas, "LDP Specification", RFC 5036, January 2001.
9.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for [RFC2544] Bradner, S. and McQuaid, J., "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network [RFC1242] Bradner, S., Editor, "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991. Interconnection Devices", RFC 1242, July 1991.
[RFC3031] Rosen et al., "Multiprotocol Label Switching
Architecture", Rosen et al., RFC 3031, August 1999.
[RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
B. Thomas, "LDP Specification", RFC 5036, January 2001.
10.2. Informative References
[RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for [RFC5180] Popoviciu, C., et al, "IPv6 Benchmarking Methodology for
Network Interconnect Devices", RFC 5180, May 2008. Network Interconnect Devices", RFC 5180, May 2008.
[RFC5151] Farrel, et al, "Inter-Domain MPLS and GMPLS Traffic [RFC5151] Farrel, et al, "Inter-Domain MPLS and GMPLS Traffic
Engineering --Resource Reservation Protocol-Traffic Engineering --Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 5151, Feb 2008. Engineering (RSVP-TE) Extensions", RFC 5151, Feb 2008.
Author's Addresses Author's Addresses
Aamer Akhter Aamer Akhter
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
RTP, NC 27709 RTP, NC 27709
USA USA
Phone: 919 392 2564
Email: aakhter@cisco.com Email: aakhter@cisco.com
Rajiv Asati Rajiv Asati
Cisco Systems Cisco Systems
7025 Kit Creek Road 7025 Kit Creek Road
RTP, NC 27709 RTP, NC 27709
USA USA
Phone: 919 392 8558
Email: rajiva@cisco.com Email: rajiva@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
skipping to change at page 21, line 23 skipping to change at line 793
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
Acknowledgment
Special thanks to Scott Bradner for his very insightful comments
delivered on very short notice.
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 102 change blocks. 
220 lines changed or deleted 214 lines changed or added

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