draft-ietf-bmwg-mpls-forwarding-meth-02.txt   draft-ietf-bmwg-mpls-forwarding-meth-03.txt 
BMWG Working Group Aamer Akhter BMWG Aamer Akhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Informational Intended status: Informational
Expires: September 2009 Rajiv Asati Expires: October 21, 2009 Rajiv Asati
Cisco Systems Cisco Systems
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
March 8, 2009 April 21, 2009
MPLS Forwarding Benchmarking Methodology for IP Flows MPLS Forwarding Benchmarking Methodology for IP Flows
draft-ietf-bmwg-mpls-forwarding-meth-02.txt draft-ietf-bmwg-mpls-forwarding-meth-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or made material from IETF Documents or IETF Contributions published or made
publicly available before November 10, 2008. The person(s) publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an material outside the IETF Standards Process. Without obtaining an
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 September 8, 2009. This Internet-Draft will expire on October 21, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your Please review these documents carefully, as they describe your
skipping to change at page 4, line 13 skipping to change at page 4, line 13
Layer 2 MPLS-VPNs, and MPLS Traffic-Engineering. Layer 2 MPLS-VPNs, and MPLS Traffic-Engineering.
However, there is no standard method defined to compare and contrast However, there is no standard method defined to compare and contrast
the foundational MPLS packet forwarding capabilities of network the foundational MPLS packet forwarding capabilities of network
devices. This document proposes a methodology using common criteria devices. This document proposes a methodology using common criteria
(such as throughput, latency, frame loss rate, system recovery, (such as throughput, latency, frame loss rate, system recovery,
reset etc.) to evaluate MPLS forwarding of any implementation. reset etc.) to evaluate MPLS forwarding of any implementation.
2. Document Scope 2. Document Scope
The benchmarking methodlogy principles outlined in RFC2544 [RFC2544] The benchmarking methodology principles outlined in RFC2544
are independent of forwarding techniques, however, they don't fully [RFC2544] are independent of forwarding techniques, however, they
address the MPLS benchmarking (note that MPLS forwarding places a don't fully address MPLS benchmarking. The fact that MPLS forwarding
different burden on the resources of the network forwarding devices places a different burden on the resources of the network forwarding
from that of IP forwarding). devices from that of IP forwarding, MPLS forwarding benchmarking
specifics are desired.
The purpose of this document is to describe a methodology specific The purpose of this document is to describe a methodology specific
to the benchmarking of MPLS forwarding devices. The methods to the benchmarking of MPLS forwarding devices. The methods
described are limited in scope to the most common MPLS packet described are limited in scope to the most common MPLS packet
forwarding scenarios and corresponding performance measurements in a forwarding scenarios and corresponding performance measurements in a
laboratory setting. It builds upon the tenets set forth in RFC2544 laboratory setting. It builds upon the tenets set forth in RFC2544
[RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology [RFC2544], RFC1242 [RFC1242] and other IETF Benchmarking Methodology
Working Group (BMWG) efforts. In other words, this document is not a Working Group (BMWG) efforts. In other words, this document is not a
replacement for, but a complement to, RFC 2544. replacement for, but a complement to, RFC 2544.
This document focuses on the MPLS label stack [RFC3032] having only This document focuses on the MPLS label stack [RFC3032] having only
one entry, as it is the fundamental of MPLS forwarding. It is one entry, as it is the fundamental of MPLS forwarding. It is
expected that future documents may cover the benchmarking of MPLS expected that future documents may cover the benchmarking of MPLS
applications such as L3VPN [RFC4364], L2VPN [RFC4664] that require applications such as L3VPN [RFC4364], L2VPN [RFC4664], Fast ReRoute
more than one entry in the MPLS label stack. [RFC4090] etc., which require more than one entry in the MPLS label
stack.
Moreover, to address majority of current deployments' needs, this Moreover, to address the majority of current deployments' needs,
document focuses on having IP packet as the MPLS payload. In other this document focuses on having IP packets as the MPLS payload. In
words, label distribution for IP Forwarding Equivalence Class other words, label distribution for IP Forwarding Equivalence Class
(FEC)[RFC3031] is prescribed (see Section 4.1.2) by this document. (FEC)[RFC3031] is prescribed (see Section 4.1.2) by this document.
It is expected that future documents may focus on having non-IP It is expected that future documents may focus on having non-IP
packets as the MPLS payload. packets as the MPLS payload.
Note that the presence of an MPLS label stack does not require the Note that the presence of an MPLS label stack does not require the
length of MPLS payload (which is an IP packet, per this document) to length of MPLS payload (which is an IP packet, per this document) to
be changed, hence, the effective maximum size of a frame can be changed, hence, the effective maximum size of a frame can
increase by Z bytes (where Z = 4 x number of label stack entries), increase by Z bytes (where Z = 4 x number of label stack entries),
as observed in current deployments. This document focusses on as observed in current deployments. This document focuses on
benchmarking such a scenario. benchmarking such a scenario.
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
skipping to change at page 6, line 9 skipping to change at page 6, line 9
Figure 1 Topology for MPLS Forwarding Benchmarking Figure 1 Topology for MPLS Forwarding Benchmarking
A represents a Tx-side Module of the test tool, whereas B represents A represents a Tx-side Module of the test tool, whereas B represents
an Rx-side Module of the same test tool. Of course, the suffixed an Rx-side Module of the same test tool. Of course, the suffixed
numbers (1, 2...p) represent ports on a Module. numbers (1, 2...p) represent ports on a Module.
Similarly, DA represents an Rx-side Module of the DUT, whereas DB Similarly, DA represents an Rx-side Module of the DUT, whereas DB
represents Tx-side Module. The suffixed numbers (1, 2...p) represent represents Tx-side Module. The suffixed numbers (1, 2...p) represent
ports on a Module. ports on a Module.
p = number of {DA, DB} pair ports on DUT; determined by the maximum p = number of {DA, DB} pair ports on DUT. It is determined by the
unidirectional forwarding throughput of the DUT and the load maximum unidirectional forwarding throughput of the DUT and the load
capacity of the port media (e.g. interface) connecting the DUT to capacity of the port media (e.g. interface) connecting the DUT to
the test tool. the test tool.
For example, if the DUT's maximum forwarding throughput is 100 For example, if the DUT's maximum forwarding throughput is 100
frames per second (fps), and the load capacity of the port media frames per second (fps), and the load capacity of the port media
(e.g. interface) is 50 fps, then p => 2 is needed to sufficiently (e.g. interface) is 50 fps, then p => 2 is needed to sufficiently
test the maximum frame forwarding. test the maximum frame forwarding.
The exact throughput is a measured quantity obtained through The exact throughput is a measured quantity obtained through
testing. Throughput may vary depending on the number of ports used, testing. Throughput may vary depending on the number of ports used,
skipping to change at page 7, line 13 skipping to change at page 7, line 13
p := Port number (i.e. Port on the Module; could be 1, 2 etc.) p := Port number (i.e. Port on the Module; could be 1, 2 etc.)
RN := Remote Network (i.e. network that is reachable via a port of a RN := Remote Network (i.e. network that is reachable via a port of a
module; could be B1RN1 or B2RN5 to mean the first network reachable module; could be B1RN1 or B2RN5 to mean the first network reachable
via port 1 of module B e.g. B1, or the 5th network reachable via via port 1 of module B e.g. B1, or the 5th network reachable via
port 2 of module B, etc.). RN is considered to be the FEC from MPLS port 2 of module B, etc.). RN is considered to be the FEC from MPLS
perpsective. perpsective.
4.1.2. IGP Support 4.1.2. IGP Support
It is highly RECOMMENDED that all of the ports (A1, DA1, DB1, and It is highly RECOMMENDED that all of the ports (A1, DA1, DB1, and
A2) on DUT and test tool support a dynamic routing protocol (IGP) A2) on DUT and test tool support a dynamic Interior Gateway Protocol
such as IS-IS, OSPF, EIGRP, RIP etc. Furthermore, there are testing (IGP) for routing such as IS-IS, OSPF, EIGRP, RIP etc. Furthermore,
considerations in this document that the device is able to provide a there are testing considerations in this document that the device be
stable control-plane during heavy forwarding workloads. This is to able to provide a stable control-plane during heavy forwarding
ensure that control plane instability during load conditions is not workloads. This is to ensure that control plane instability during
the contributing factor towards frame forwarding performance. load conditions is not the contributing factor towards frame
forwarding performance.
The route distribution method (OSPF, IS-IS, EIGRP, RIP, Static The route distribution method (OSPF, IS-IS, EIGRP, RIP, Static
etc.), if used, MUST be reported. Furthermore, if any specific etc.), if used, MUST be reported. Furthermore, if any specific
configuration is used to maintain control-plane stability during the configuration is used to maintain control-plane stability during the
test (i.e. Control Plane Protection, Control Plane Rate Limiting, test (i.e. Control Plane Protection, Control Plane Rate Limiting,
etc.), then it MUST also be reported. etc.), then it MUST also be reported.
4.1.3. Label Distribution Support 4.1.3. 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
skipping to change at page 9, line 11 skipping to change at page 9, line 11
MPLS label values used in any testcase MUST be outside the reserved MPLS label values used in any testcase MUST be outside the reserved
label value (0-15) unless stated otherwise. label value (0-15) unless stated otherwise.
4.1.4.2. MPLS packet payload 4.1.4.2. MPLS packet payload
This document prescribes using IP packet as the MPLS payload (as This document prescribes using IP packet as the MPLS payload (as
illustrated in figure 2 above). Generically speaking, this document illustrated in figure 2 above). Generically speaking, this document
mandates the test frame to include IP (either IPv4 or IPv6) as the mandates the test frame to include IP (either IPv4 or IPv6) as the
layer 3 protocol, in accord with Section 8 of [RFC2544] and layer 3 protocol, in accord with Section 8 of [RFC2544] and
independent of the MPLS label stack presence, for three reasons - independent of the MPLS label stack presence, for three reasons:
1) This enables using IP Prefix Forwarding Equivalence Class (FEC) 1) This enables using IP Prefix Forwarding Equivalence Class (FEC)
[RFC3031], which is a must for every MPLS network. [RFC3031], which is a must for every MPLS network.
2) This provides the foundation or baseline for benchmarking of 2) This provides the foundation or baseline for benchmarking of
various other MPLS applications such as L3VPN, L2VPN, RSVP-TE etc. various other MPLS applications such as L3VPN, L2VPN, TE-FRR etc.
3) This enables leveraging RFC2544 [RFC2544], which prescribes using 3) This enables leveraging RFC2544 [RFC2544], which prescribes using
IP packet with UDP data as the test frames. (Note that [RFC5180] IP packet with UDP data as the test frames. (Note that [RFC5180]
also uses this prescription for IPv6 benchmarking). also uses this prescription for IPv6 benchmarking).
While the usage of non-IP payloads is possible, it requires an MPLS While the usage of non-IP payloads is possible, it requires an MPLS
application e.g. L2VPN, whose benchmarking may be covered in application e.g. L2VPN, whose benchmarking may be covered in
separate BMWG documents (MPLS L2VPN Benchmarking, for example) in separate BMWG documents (MPLS L2VPN Benchmarking, for example) in
the future. This is also explained in Section 2. the future. This is also explained in Section 2.
4.1.4.3. Change in Frame Format due to MPLS Imposition and Disposition 4.1.4.3. Change in Frame Format due to MPLS Imposition and Disposition
skipping to change at page 11, line 44 skipping to change at page 11, line 44
RFC2544) - RFC2544) -
<----------------64-1518B------------------------> <----------------64-1518B------------------------>
<--18B---><-----------46-1500B-------------------> <--18B---><-----------46-1500B------------------->
+------------------------------------------------+ +------------------------------------------------+
| Layer 2 | Layer 3 | Layer 4 (and higher) | | Layer 2 | Layer 3 | Layer 4 (and higher) |
+------------------------------------------------+ +------------------------------------------------+
Figure 3 Frame Size for Label Imposition cases Figure 3 Frame Size for Label Imposition cases
Note: The recommended 1518-byte frame size represents the maximum Note: The 64 and 1518 byte frame size represents the minimum and
size of an untagged Ethernet frame, as per IEEE 802.3 [IEE8023]. maximum length of an untagged Ethernet frame, as per IEEE 802.3
A frame size commonly used in operational environments is 1522 [IEE8023]. A frame size commonly used in operational environments
bytes, the max length for a single VLAN-tagged frame, as per IEEE may range from 68 to 1522 bytes, which are the minimum and maximum
802.1D [IEE8021]. length of a single VLAN-tagged frame, as per IEEE 802.1D
[IEE8021].
Note: While jumbo frames are outside the scope of the 802.3 IEEE Note: While jumbo frames are outside the scope of the 802.3 IEEE
standard, tests SHOULD be executed with the frame sizes that are standard, tests SHOULD be executed with the frame sizes that are
supported by the DUT. Examples of commonly used jumbo (ethernet) supported by the DUT. Examples of commonly used jumbo (ethernet)
frame sizes are: 4096, 8192, and 9216 bytes. frame sizes are: 4096, 8192, and 9216 bytes.
If any test case execution (such as Label Swap and Label Disposition If any test case execution (such as Label Swap and Label Disposition
cases) requires the testtool to transmit (or receive) a layer2 frame cases) requires the testtool to transmit (or receive) a layer2 frame
containing an MPLS packet, then the untagged layer2 frame must containing an MPLS packet, then the untagged layer2 frame must
include an additional 4 bytes for the MPLS header, resulting in the include an additional 4 bytes for the MPLS header, resulting in the
skipping to change at page 13, line 5 skipping to change at page 13, line 10
is 1500 bytes). This document prescribes Z=4 bytes. If a vendor is 1500 bytes). This document prescribes Z=4 bytes. If a vendor
DUT doesn't allow such an MTU change, then the benchmarking can DUT doesn't allow such an MTU change, then the benchmarking can
not be performed for the true maximum frame payload size [RFC3032] not be performed for the true maximum frame payload size [RFC3032]
and this must be reported. and this must be reported.
4.1.5.2. Frame Sizes to be used on POS Media 4.1.5.2. Frame Sizes to be used on POS Media
Packet over SONET (POS) media are commonly used for edge uplinks and Packet over SONET (POS) media are commonly used for edge uplinks and
high-bandwidth core links. POS may use one of various high-bandwidth core links. POS may use one of various
encapsulations techniques (such as PPP, HDLC, Frame Relay etc.), encapsulations techniques (such as PPP, HDLC, Frame Relay etc.),
resulting in layer 2 header (~4 bytes) being less than that of resulting in the layer 2 header (~4 bytes) being less than that of
ethernet media. Rest of the frame format (illustrated in figure 2 ethernet media. The rest of the frame format (illustrated in figure
and 3) remains pretty much unchanged. 2 and 3) remains pretty much unchanged.
If the MPLS forwarding characterization of POS interfaces on the DUT If the MPLS forwarding characterization of POS interfaces on the DUT
is desired, then the following frame sizes SHOULD be used for: is desired, then the following frame sizes SHOULD be used:
Label Imposition testcases: 47, 64, 128, 256, 512, 1024, 1280, Label Imposition testcases: 47, 64, 128, 256, 512, 1024, 1280,
1518, 2048 and 4096 bytes. 1518, 2048 and 4096 bytes.
Label Swap and Dispoisition testcases: 51, 68, 132, 260, 516, Label Swap and Dispoisition testcases: 51, 68, 132, 260, 516,
1028, 1284, 1522, 2052 and 4100 bytes. 1028, 1284, 1522, 2052 and 4100 bytes.
4.1.6. Time-to-Live (TTL) or Hop Limit 4.1.6. Time-to-Live (TTL) or Hop Limit
The TTL value in the frame header must be large enough to allow a The TTL value in the frame header must be large enough to allow a
skipping to change at page 14, line 12 skipping to change at page 14, line 12
verify that the DUT is able to maintain a stable control plane when verify that the DUT is able to maintain a stable control plane when
the data-forwarding plane is under stress. the data-forwarding plane is under stress.
4.1.8. Traffic Verification 4.1.8. Traffic Verification
In all cases, 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, incorrect layer2 or above header information etc.). In addition, the
presence or absence of MPLS label stack, every field value inside presence or absence of MPLS label stack, every field value inside
the label stack, if present, ethertype (0x8847 or 0x8848 vs. the label stack, if present, ethertype (0x8847 or 0x8848 vs.
0x0800), frame sequencing and frame check sequence (FCS), MUST be 0x0800), frame sequencing and frame check sequence (FCS), MUST be
verified in the received frame. verified in the received frame.
Many test tools may, by default, only verify that they have received Many test tools may, by default, only verify that they have received
the embedded signature on the receive side. However, for MPLS header the embedded signature on the receive side. However, for MPLS header
presence verification, some tests will require the MPLS header to be presence verification, some tests will require the MPLS header to be
imposed while others will require a swap or disposition. Hence, this imposed while others will require a swap or disposition. Hence, this
document requires the test tool to verify the MPLS stack depth. An document requires the test tool to verify the MPLS stack depth. An
skipping to change at page 16, line 10 skipping to change at page 16, line 10
ports per Figure 1) ports per 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 a different forwarding paradigm from IP. Unlike IP packet MPLS is a different forwarding paradigm from IP. Unlike IP packet
and IP forwarding, an MPLS packet may contain more than one MPLS and IP forwarding, an MPLS packet may contain more than one MPLS
header and may go through one of three forwarding operations - header and may go through one of three forwarding operations -
imposition (or LSP ingress), swap and disposition (or LSP egress), imposition (or LSP ingress), swap or disposition (or LSP egress), as
as defined in [RFC3031]. Such characteristics desire further defined in [RFC3031]. Such characteristics desire further
granularity in MPLS forwarding benchmarking than those described in granularity in MPLS forwarding benchmarking than those described in
RFC2544. Thus the benchmarking may include, but not limited to: RFC2544. Thus the benchmarking may include, but not limited to:
1. Throughput 1. Throughput
2. Latency 2. Latency
3. Frame Loss rate 3. Frame Loss rate
4. System Recovery 4. System Recovery
skipping to change at page 17, line 30 skipping to change at page 17, line 30
4.1.4.3. Furthermore, the IP packet must be either an IPv4 or IPv6 4.1.4.3. Furthermore, the IP packet must be either an IPv4 or IPv6
packet, depending on whether the MPLS benchmarking is done for packet, depending on whether the MPLS benchmarking is done for
IPv4 or IPv6. IPv4 or IPv6.
If any frame loss is detected, then a new iteration is needed If any frame loss is detected, then a new iteration is needed
where the offered load is decreased and the sender will transmit where the offered load is decreased and the sender will transmit
again. An iterative search algorithm MUST be used to determine the again. An iterative search algorithm MUST be used to determine the
maximum offered frame rate with a zero frame loss. maximum offered frame rate with a zero frame loss.
This maximum offered frame rate that results in zero frame loss This maximum offered frame rate that results in zero frame loss
through the DUT is commonly referred to as the No Drop Rate (NDR) through the DUT is defined as the Throughput in Section 3.17 of
for that test case. [RFC1242] for that test case. Informally, this rate is referred to
as the No Drop Rate.
Each iteration should involve varying the offered load of the Each iteration should involve varying the offered load of the
traffic, while keeping the other parameters (test duration, number traffic, while keeping the other parameters (test duration, number
of ports, number of addresses, frame size etc) constant, until the of ports, number of addresses, frame size etc) constant, until the
maximum rate at which none of the offered frames are dropped is maximum rate at which none of the offered frames are dropped is
determined. 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
skipping to change at page 22, line 29 skipping to change at page 22, line 29
Objective Objective
To obtain the DUT's Throughput (as per RFC 2544) during label To obtain the DUT's Throughput (as per RFC 2544) during label
disposition (i.e. MPLS to IP) or penultimate hop popping (PHP) disposition (i.e. MPLS to IP) or penultimate hop popping (PHP)
using "imp-null" outgoing label. using "imp-null" outgoing 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 4.1.2) and associated MPSL label-FEC binding with a per Section 4.1.2) and associated MPLS label-FEC binding with a
reserved MPLS label value = 3 (using a label distribution protocol reserved MPLS label value = 3 (using a label distribution protocol
as per Section 4.1.3) on its receive ports Bp. The test tool must as per Section 4.1.3) on its receive ports Bp. The test tool must
learn the IP prefix(es) as well as the MPLS label-FEC bindings on learn the IP prefix(es) as well as the MPLS label-FEC bindings on
its transmit ports Ap. The test tool then must use the learned its transmit ports Ap. The test tool then must use the learned
MPLS label values and learned IP prefix values in the frames MPLS label values and learned IP prefix values in the frames
transmitted on ports Ap to DUT. The test tool must receive frames transmitted on ports Ap to DUT. The test tool must receive frames
containing IP packets on receive ports Bp (from DUT). containing IP packets on receive ports Bp (from DUT).
MPLS and/or label distribution protocol must be enabled on the MPLS and/or label distribution protocol must be enabled on the
test tool ports Bp and Ap, and DUT ports DBp and DAp. test tool ports Bp and Ap, and DUT ports DBp and DAp.
Discussion Discussion
This test case characterizes the Penultimate Hop Popping (PHP), This test case characterizes the Penultimate Hop Popping (PHP),
which is described in RFC3031. which is described in RFC3031.
The DUT's MPLS forwarding table (also referred to as FEC-to-NHLFE The DUT's MPLS forwarding table (also referred to as FEC-to-
(FTN) mapping table per [RFC3031]) must contain a reserved MPLS Next_Hop_Label_Forwarding_Entry (FTN) mapping table per [RFC3031])
label value = 3 (e.g. pop or imp-null) as the outgoing label for must contain a reserved MPLS label value = 3 (e.g. pop or imp-
the learned prefix(es), resulting in MPLS-to-IP forwarding null) as the outgoing label for the learned prefix(es), resulting
operation. in MPLS-to-IP forwarding operation.
This test case characterizes DUT's penultimate hop popping (PHP) This test case characterizes DUT's penultimate hop popping (PHP)
functionality. functionality.
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 frames containing MPLS packets on its transmit tool must send frames containing MPLS packets on its transmit
ports Ap (with IP destination belonging to advertised IP ports Ap (with IP destination belonging to advertised IP
prefix(es)), and expect to receive frames containing IP packets on prefix(es)), and expect to receive frames containing IP packets on
skipping to change at page 23, line 33 skipping to change at page 23, line 33
for each of the tested frame sizes. for each of the tested frame sizes.
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 an MPLS label stack. MPLS or MPLS-to-IP involving an MPLS label stack.
Objective Objective
To obtain the maximum latency induced by the DUT during MPLS To obtain the average latency induced by the DUT during MPLS
packet forwarding for each of three forwarding operations. packet forwarding for each of five forwarding operations.
Test Setup Test Setup
Follow the Test Setup guidelines established for each of four MPLS Follow the Test Setup guidelines established for each of four MPLS
forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2 forwarding operations in Section 6.1.1 (for IP-to-MPLS), 6.1.2
(for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for (for MPLS-to-MPLS), 6.1.3 (for MPLS-to-IP Unlabeled), 6.1.4 (for
MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one. MPLS-to-IP Aggregate) and 6.1.5 (for MPLS-to-IP PHP) one by one.
Procedure Procedure
skipping to change at page 27, line 17 skipping to change at page 27, line 17
Benchmarking activities, as described in this memo, are limited to Benchmarking activities, as described in this memo, are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
traffic into a production network or misroute traffic to the test traffic into a production network or misroute traffic to the test
management network. management network.
Furthermore, benchmarking is performed on a "black-box" basis,
relying solely on measurements observable external to the DUT/SUT.
Special capabilities SHOULD NOT exist in the DUT/SUT specifically
for benchmarking purposes. Any implications for network security
arising from the DUT/SUT SHOULD be identical in the lab and in
production networks.
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. Acknowledgement 9. Acknowledgement
The authors would like to thank Mo Khalid, who motivated us to write The authors would like to thank Mo Khalid, who motivated us to write
this document. We would like to thank Rodney Dunn, Chip Popoviciu, this document. We would like to thank Rodney Dunn, Chip Popoviciu,
Jay Karthik, Rajiv Pap, Samir Vapiwala, Silvija Andrijic Dry, Scott Jeff Byzek, Jay Karthik, Rajiv Pap, Samir Vapiwala, Silvija Andrijic
Bradner, Al Morton and Bill Cerveny for their careful review and Dry, Scott Bradner, Al Morton and Bill Cerveny for their careful
suggestions. review and suggestions.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 29, line 23 skipping to change at page 29, line 23
[RFC2328] Moy, J., "OSPF Version 2", RFC2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC2328, April 1998.
[RFC5462] Asati, R. and Andersson, L., "Multi-Protocol Label [RFC5462] Asati, R. and Andersson, L., "Multi-Protocol Label
Switching (MPLS) label stack entry: "EXP" field renamed to Switching (MPLS) label stack entry: "EXP" field renamed to
"Traffic Class" field", RFC5462, Feb 2009. "Traffic Class" field", RFC5462, Feb 2009.
[RFC4928] Swallow, et al., "Avoiding Equal Cost Multipath Treatment [RFC4928] Swallow, et al., "Avoiding Equal Cost Multipath Treatment
in MPLS Networks", RFC4928, June 2007. in MPLS Networks", RFC4928, June 2007.
[RFC4090] Pan, et al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC4090, May 2005.
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
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
Email: rajiva@cisco.com Email: rajiva@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
 End of changes. 26 change blocks. 
52 lines changed or deleted 67 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/