draft-ietf-bmwg-mpls-forwarding-meth-03.txt   draft-ietf-bmwg-mpls-forwarding-meth-04.txt 
BMWG Aamer Akhter BMWG Aamer Akhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Informational Intended status: Informational
Expires: October 21, 2009 Rajiv Asati Expires: January 9, 2009 Rajiv Asati
Cisco Systems Cisco Systems
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
April 21, 2009 July 9, 2009
MPLS Forwarding Benchmarking Methodology for IP Flows MPLS Forwarding Benchmarking Methodology for IP Flows
draft-ietf-bmwg-mpls-forwarding-meth-03.txt draft-ietf-bmwg-mpls-forwarding-meth-04.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 October 21, 2009. This Internet-Draft will expire on October 9, 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 3, line 24 skipping to change at page 3, line 24
4.1.3. Label Distribution Support.................................7 4.1.3. Label Distribution Support.................................7
4.1.4. Frame Formats..............................................8 4.1.4. Frame Formats..............................................8
4.1.5. Frame Sizes...............................................10 4.1.5. Frame Sizes...............................................10
4.1.6. Time-to-Live (TTL) or Hop Limit...........................13 4.1.6. Time-to-Live (TTL) or Hop Limit...........................13
4.1.7. Trial Duration............................................13 4.1.7. Trial Duration............................................13
4.1.8. Traffic Verification......................................14 4.1.8. Traffic Verification......................................14
4.1.9. Address Resolution and Dynamic Protocol State.............14 4.1.9. Address Resolution and Dynamic Protocol State.............14
5. Reporting Format..............................................15 5. Reporting Format..............................................15
6. MPLS Forwarding Benchmarking Tests............................16 6. MPLS Forwarding Benchmarking Tests............................16
6.1. Throughput..................................................18 6.1. Throughput..................................................18
6.1.1. Throughput for MPLS Label Imposition......................18 6.1.1. Throughput for MPLS Label Push............................18
6.1.2. Throughput for MPLS Label Swap............................19 6.1.2. Throughput for MPLS Label Swap............................19
6.1.3. Throughput for MPLS Label Disposition (Unlabeled).........20 6.1.3. Throughput for MPLS Label Pop (Unlabeled).................20
6.1.4. Throughput for MPLS Label Disposition (Aggregate).........21 6.1.4. Throughput for MPLS Label Pop (Aggregate).................21
6.1.5. Throughput for MPLS Label Disposition (PHP)...............22 6.1.5. Throughput for MPLS Label Pop (PHP).......................22
6.2. Latency Measurement.........................................23 6.2. Latency Measurement.........................................23
6.3. Frame Loss Rate Measurement (FLR)...........................24 6.3. Frame Loss Rate Measurement (FLR)...........................24
6.4. System Recovery.............................................25 6.4. System Recovery.............................................25
6.5. Reset.......................................................26 6.5. Reset.......................................................26
7. Security Considerations.......................................27 7. Security Considerations.......................................27
8. IANA Considerations...........................................27 8. IANA Considerations...........................................27
9. Acknowledgement...............................................27 9. Acknowledgement...............................................28
10. References...................................................28 10. References...................................................29
10.1. Normative References.......................................28 10.1. Normative References.......................................29
10.2. Informative References.....................................28 10.2. Informative References.....................................29
Author's Addresses...............................................29 Author's Addresses...............................................30
1. Introduction 1. Introduction
Over the past several years, there has been an increase in the use Over the past several years, there has been an increase in the use
of MPLS as a forwarding architecture in new and existing network of MPLS as a forwarding architecture in new and existing network
designs. MPLS, defined in [RFC3031], is a foundation technology and designs. MPLS, defined in [RFC3031], is a foundation technology and
basis for many advanced technologies such as Layer 3 MPLS-VPNs, basis for many advanced technologies such as Layer 3 MPLS-VPNs,
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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
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 Interior Gateway Protocol A2) on DUT and test tool support a dynamic Interior Gateway Protocol
(IGP) for routing such as IS-IS, OSPF, EIGRP, RIP etc. Furthermore, (IGP) for routing such as IS-IS, OSPF, RIP etc. Furthermore, there
there are testing considerations in this document that the device be are testing considerations in this document that the device be able
able to provide a stable control-plane during heavy forwarding to provide a stable control-plane during heavy forwarding workloads.
workloads. This is to ensure that control plane instability during In particular, the procedures defined in section 11.3 of RFC2544
load conditions is not the contributing factor towards frame must be followed. This is to ensure that control plane instability
during load conditions is not the contributing factor towards frame
forwarding performance. 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
skipping to change at page 9, line 26 skipping to change at page 9, line 26
various other MPLS applications such as L3VPN, L2VPN, TE-FRR 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 Push and Pop
A frame carrying IP or MPLS packet may go through any of the three A frame carrying IP or MPLS packet may go through any of the three
MPLS forwarding operations: label imposition (or LSP Ingress), label MPLS forwarding operations: label push (or LSP Ingress), label swap
swap and label disposition (or LSP Egress), as defined in [RFC3031]. and label pop (or LSP Egress), as defined in [RFC3031]. It is
It is important to understand the change of the frame format from IP important to understand the change of the frame format from IP to
to MPLS or vice versa depending on the forwarding operation. MPLS or vice versa depending on the forwarding operation.
In label imposition (or LSP ingress) operation, the DUT receives a In label push (or LSP ingress) operation, the DUT receives a frame
frame containing an IP packet and forwards a frame containing an containing an IP packet and forwards a frame containing an MPLS
MPLS packet if the corresponding forwarding lookup for the IP packet if the corresponding forwarding lookup for the IP destination
destination points to a label imposition operation. points to a label push operation.
In label swap operation, the DUT receives a frame containing an MPLS In label swap operation, the DUT receives a frame containing an MPLS
packet and forwards a frame containing an MPLS packet if the packet and forwards a frame containing an MPLS packet if the
corresponding forwarding lookup for the label value points to a corresponding forwarding lookup for the label value points to a
label swap operation. label swap operation.
In label disposition (or LSP egress) operation, the DUT receives a In label pop (or LSP egress) operation, the DUT receives a frame
frame containing an MPLS packet and forwards a frame containing an containing an MPLS packet and forwards a frame containing an IP
IP packet if the corresponding forwarding lookup for the label value packet if the corresponding forwarding lookup for the label value
points to a label disposition operation. points to a label pop operation.
4.1.4.4. Frame Formats to be used for Benchmarking 4.1.4.4. Frame Formats to be used for Benchmarking
This document prescribes using two test frame formats to This document prescribes using two test frame formats to
appropriately test the forwarding operations: (1) Frame format for appropriately test the forwarding operations: (1) Frame format for
IP and (2) Frame format for MPLS. Both formats are explained in IP and (2) Frame format for MPLS. Both formats are explained in
Section 4.1.3.1. Additionally, the format of the test frame may Section 4.1.3.1. Additionally, the format of the test frame may
change depending on the forwarding operation. change depending on the forwarding operation.
1. For testcases involving label imposition operation - the test 1. For testcases involving label push operation - the test tool must
tool must use the frame format for IP packet (figure 1) to send use the frame format for IP packet (figure 1) to send the test
the test frames to the DUT, and must use the frame format for MPLS frames to the DUT, and must use the frame format for MPLS packet
packet (figure 2) to receive the test frames from the DUT. (figure 2) to receive the test frames from the DUT.
2. For testcases involving label swap operation - the test tool must 2. For testcases involving label swap operation - the test tool must
use the frame format for MPLS packet (figure 2) to send the test use the frame format for MPLS packet (figure 2) to send the test
frames to the DUT, and must use the frame format for MPLS packet frames to the DUT, and must use the frame format for MPLS packet
(figure 2) to receive the test frames from the DUT. (figure 2) to receive the test frames from the DUT.
3. For testcases involving label disposition operation - the test 3. For testcases involving label pop operation - the test tool must
tool must use the frame format for MPLS packet (figure 2) to send use the frame format for MPLS packet (figure 2) to send the test
the test frames to the DUT, and must use the frame format for IP frames to the DUT, and must use the frame format for IP packet
packet (figure 1) to receive the test frames from the DUT. (figure 1) to receive the test frames from the DUT.
4.1.5. Frame Sizes 4.1.5. Frame Sizes
Two types of port media are commonly deployed: Ethernet and POS Two types of port media are commonly deployed: Ethernet and POS
(Packet Over Synchronous Optical Network). This section identifies (Packet Over Synchronous Optical Network). This section identifies
the frame sizes that SHOULD be used for each media type, if the frame sizes that SHOULD be used for each media type, if
supported by the DUT. Section 4.1.4.1 covers Ethernet and 4.1.4.2 supported by the DUT. Section 4.1.4.1 covers Ethernet and 4.1.4.2
covers POS. covers POS.
First, it is important to note the possible increase in frame size First, it is important to note the possible increase in frame size
skipping to change at page 11, line 28 skipping to change at page 11, line 28
the frame size ordering and usage). There is no standard for the frame size ordering and usage). There is no standard for
mixtures of frame sizes, and the results are subject to wide mixtures of frame sizes, and the results are subject to wide
interpretation. See Section 18 of RFC 2544. When running trials interpretation. See Section 18 of RFC 2544. When running trials
using multiple simultaneous frame sizes, the DUT configuration MUST using multiple simultaneous frame sizes, the DUT configuration MUST
remain the same. remain the same.
4.1.5.1. Frame Sizes to be used on Ethernet Media 4.1.5.1. Frame Sizes to be used on Ethernet Media
Ethernet media, in all its types, has become the most commonly Ethernet media, in all its types, has become the most commonly
deployed port media in MPLS networks. If any test case execution deployed port media in MPLS networks. If any test case execution
(such as Label Imposition case) requires the testtool to send (or (such as Label Push case) requires the testtool to send (or receive)
receive) a layer2 frame containing an IP packet, then the following a layer2 frame containing an IP packet, then the following frame
frame sizes SHOULD be used for benchmarking over ethernet media: sizes SHOULD be used for benchmarking over ethernet media: 64, 128,
64, 128, 256, 512, 1024, 1280 and 1518 bytes. This is in line with 256, 512, 1024, 1280 and 1518 bytes. This is in line with Section 9
Section 9 and 9.1 of RFC2544. Figure 1 illustrates the header sizes and 9.1 of RFC2544. Figure 1 illustrates the header sizes for an
for an untagged ethernet frame containing an IP payload (per untagged ethernet frame containing an IP payload (per 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 Push cases
Note: The 64 and 1518 byte frame size represents the minimum and Note: The 64 and 1518 byte frame size represents the minimum and
maximum length of an untagged Ethernet frame, as per IEEE 802.3 maximum length of an untagged Ethernet frame, as per IEEE 802.3
[IEE8023]. A frame size commonly used in operational environments [IEE8023]. A frame size commonly used in operational environments
may range from 68 to 1522 bytes, which are the minimum and maximum may range from 68 to 1522 bytes, which are the minimum and maximum
length of a single VLAN-tagged frame, as per IEEE 802.1D length of a single VLAN-tagged frame, as per IEEE 802.1D
[IEE8021]. [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 Pop cases)
cases) requires the testtool to transmit (or receive) a layer2 frame 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
following frame sizes to be used for benchmarking over ethernet following frame sizes to be used for benchmarking over ethernet
media: 68, 132, 260, 516, 1028, 1284 and 1522 bytes. Figure 2 media: 68, 132, 260, 516, 1028, 1284 and 1522 bytes. Figure 2
illustrates the header sizes for an untagged ethernet frame illustrates the header sizes for an untagged ethernet frame
containing an MPLS packet - containing an MPLS packet -
<------------------68-1522B------------------------------> <------------------68-1522B------------------------------>
<--18B---><--4B--><-----------46-1500B-------------------> <--18B---><--4B--><-----------46-1500B------------------->
+--------------------------------------------------------+ +--------------------------------------------------------+
| Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) | | Layer 2 | MPLS | Layer 3 | Layer 4 (and higher) |
+--------------------------------------------------------+ +--------------------------------------------------------+
Figure 4 Frame Size for Label Swap and Disposition cases. Figure 4 Frame Size for Label Swap and Pop cases.
Note: The Media MTU on the link between the testtool and DUT must Note: The Media MTU on the link between the testtool and DUT must
be changed, if needed, to accommodate the effective maximum frame be changed, if needed, to accommodate the effective maximum frame
payload size [RFC3032] resulting from adding an MPLS label stack payload size [RFC3032] resulting from adding an MPLS label stack
to the IP packet. As clarified in Section 3.1 of RFC3032, most to the IP packet. As clarified in Section 3.1 of RFC3032, most
layer 2 media drivers are capable of sending and receiving layer 2 layer 2 media drivers are capable of sending and receiving layer 2
frames with effective maximum frame payload size. Many vendors frames with effective maximum frame payload size. Many vendors
also allow the Media MTU to be changed for MPLS, without changing also allow the Media MTU to be changed for MPLS, without changing
it for IP. The recommended link MTU value for MPLS is Z bytes more it for IP. The recommended link MTU value for MPLS is Z bytes more
than the conventional maximum frame payload size [RFC3032] (for than the conventional maximum frame payload size [RFC3032] (for
skipping to change at page 13, line 17 skipping to change at page 13, line 12
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 the 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. The rest of the frame format (illustrated in figure ethernet media. The rest of the frame format (illustrated in figure
2 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: is desired, then the following frame sizes SHOULD be used:
Label Imposition testcases: 47, 64, 128, 256, 512, 1024, 1280, Label Push testcases: 47, 64, 128, 256, 512, 1024, 1280, 1518,
1518, 2048 and 4096 bytes. 2048 and 4096 bytes.
Label Swap and Dispoisition testcases: 51, 68, 132, 260, 516, Label Swap and Pop testcases: 51, 68, 132, 260, 516, 1028, 1284,
1028, 1284, 1522, 2052 and 4100 bytes. 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
TTL decrement to happen and still be forwared through the DUT. The TTL decrement to happen and still be forwared through the DUT. The
TTL field may either be MPLS TTL, IPV4 TTL, or IPV6 Hop Limit TTL field may either be MPLS TTL, IPV4 TTL, or IPV6 Hop Limit
depending on the exact forwarding scenario under evaluation. depending on the exact forwarding scenario under evaluation.
If TTL/Hop Limit Decrement, as specified in [RFC3443], is a If TTL/Hop Limit Decrement, as specified in [RFC3443], is a
configurable option on the DUT, the setting SHOULD be reported. configurable option on the DUT, the setting SHOULD be reported.
skipping to change at page 14, line 21 skipping to change at page 14, line 21
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, 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 pushed while others will require a swap or pop. Hence, this document
document requires the test tool to verify the MPLS stack depth. An requires the test tool to verify the MPLS stack depth. An even
even greater level of verification would be to check if the correct greater level of verification would be to check if the correct label
label was imposed, but that is out of scope for these tests. was pushed, but that is out of scope for these tests.
4.1.9. Address Resolution and Dynamic Protocol State 4.1.9. Address Resolution and Dynamic Protocol State
If a test setup utilizes any dynamic protocols for control plane If a test setup utilizes any dynamic protocols for control plane
signalling (eg. ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then signalling (eg. ARP, PPP (including MPLSCP), OSPF, LDP, etc.), then
all state for the protocols MUST be pre-established bofore the test all state for the protocols MUST be pre-established bofore the test
case is executed (i.e. packet streams are started). case is executed (i.e. packet streams are started).
5. Reporting Format 5. Reporting Format
skipping to change at page 15, line 19 skipping to change at page 15, line 19
test case: test case:
Parameter Units or Examples Parameter Units or Examples
Prefix Forwarding IPv4, IPv6, Both Prefix Forwarding IPv4, IPv6, Both
Equivalence Class (FEC) Equivalence Class (FEC)
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 Push, Swap, Pop
Disposition
IGP ISIS, OSPF, EIGRP, RIP, IGP ISIS, OSPF, EIGRP, RIP,
static. static.
Throughput Frames per second and Throughput Frames per second and
Bits per second Bits per second
Port Media GigE, POS, ATM etc. Port Media GigE, POS, ATM etc.
Port Speed 1 gbps, 100 Mbps, etc. Port Speed 1 gbps, 100 Mbps, etc.
skipping to change at page 16, line 9 skipping to change at page 16, line 9
p (Number of {DA, DB} pair 1,2, etc. p (Number of {DA, DB} pair 1,2, etc.
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 - push
imposition (or LSP ingress), swap or disposition (or LSP egress), as (or LSP ingress), swap or pop (or LSP egress), as defined in
defined in [RFC3031]. Such characteristics desire further [RFC3031]. Such characteristics desire further granularity in MPLS
granularity in MPLS forwarding benchmarking than those described in forwarding benchmarking than those described in RFC2544. Thus the
RFC2544. Thus the benchmarking may include, but not limited to: 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
5. Reset 5. Reset
skipping to change at page 18, line 10 skipping to change at page 18, line 10
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
to the characterization of DUT's MPLS traffic 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 Push
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 push
imposition or LSP Ingress forwarding operation (i.e. IP to MPLS). or LSP Ingress forwarding operation (i.e. IP to MPLS).
Test Setup Test Setup
In addition to the test setup described in Section 6, the test In addition to the test setup described in Section 6, the test
tool must advertise the IP prefix(es) i.e. RNx (using a routing tool must advertise the IP prefix(es) i.e. RNx (using a routing
protocol as per Section 4.1.2) and associated MPLS label-FEC protocol as per Section 4.1.2) and associated MPLS label-FEC
binding(s) (using a label distribution protocol as per Section binding(s) (using a label distribution protocol as per Section
4.1.3) on its receive ports Bp to DUT. The test tool may learn the 4.1.3) on its receive ports Bp to DUT. The test tool may learn the
IP prefix(es) on it's transmit ports Ap from DUT. IP prefix(es) on it's transmit ports Ap from DUT.
skipping to change at page 20, line 14 skipping to change at page 20, line 14
Ap, and expect to receive frames containing MPLS packets on its Ap, and expect to receive frames containing MPLS packets on its
receive ports Bp, as described in Section 4.1.4.4. receive ports Bp, as described in Section 4.1.4.4.
Reporting Format Reporting Format
The result should be reported as per Section 5 and as per RFC2544. The result should be reported as per Section 5 and as per RFC2544.
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. for each of the tested frame sizes.
6.1.3. Throughput for MPLS Label Disposition (Unlabeled) 6.1.3. Throughput for MPLS Label Pop (Unlabeled)
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 pop
disposition or LSP Egress forwaridng operation (i.e. MPLS to IP) or LSP Egress forwaridng operation (i.e. MPLS to IP) using
using "Unlabeled" outgoing label. "Unlabeled" outgoing label.
Test Setup Test Setup
In addition to setup described in Section 6, the test tool must In addition to setup described in Section 6, the test tool must
advertise the IP prefix(es) (using a routing protocol as per advertise the IP prefix(es) (using a routing protocol as per
Section 4.1.2) without any MPLS label-FEC bindings on the receive Section 4.1.2) without any MPLS label-FEC bindings on the receive
ports Bp, and then learn the IP prefix(es) as well as the FEC- ports Bp, and then learn the IP prefix(es) as well as the FEC-
label binding(s) on the transmit ports Ap. The test tool must use label binding(s) on the transmit ports Ap. The test tool must use
the learned MPLS label values and learned IP prefix values in the the learned MPLS label values and learned IP prefix values in the
frames transmitted on ports Ap. frames transmitted on ports Ap.
skipping to change at page 21, line 12 skipping to change at page 21, line 12
advertised on port Bp), and expect to receive frames containing IP advertised on port Bp), and expect to receive frames containing IP
packets on its receive ports Bp, as described in Section 4.1.4.4. packets on its receive ports Bp, as described in Section 4.1.4.4.
Reporting Format Reporting Format
The result should be reported as per Section 5 and as per RFC2544. The result should be reported as per Section 5 and as per RFC2544.
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. for each of the tested frame sizes.
6.1.4. Throughput for MPLS Label Disposition (Aggregate) 6.1.4. Throughput for MPLS Label Pop (Aggregate)
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 pop
disposition or LSP Egress forwarding operation (i.e. MPLS to IP) or LSP Egress forwarding operation (i.e. MPLS to IP) using
using "Aggregate" outgoing label. "Aggregate" outgoing label[RFC3031].
Test Setup Test Setup
In addition to setup described in Section 6, the DUT must be In addition to setup described in Section 6, the DUT must be
provisioned such that it allocates an aggregate outgoing label provisioned such that it allocates an aggregate outgoing label
(please see Section 3.20 in [RFC3031]) to an IP prefix, which (please see Section 3.20 in [RFC3031]) to an IP prefix, which
aggregates a set of prefixes learned on ports DBp from the test aggregates a set of prefixes learned on ports DBp from the test
tool. The prefix aggregation can be performed using BGP tool. The prefix aggregation can be performed using BGP
aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation aggregation (Section 9.2.2.2 of [RFC4271]), IGP aggregation
(Section 16.5 of [RFC2328]), etc.). (Section 16.5 of [RFC2328]), etc.).
skipping to change at page 22, line 17 skipping to change at page 22, line 17
advertised on port Bp), and expect to receive frames containing IP advertised on port Bp), and expect to receive frames containing IP
packets on its receive ports Bp, as described in Section 4.1.4.4. packets on its receive ports Bp, as described in Section 4.1.4.4.
Reporting Format Reporting Format
The result should be reported as per Section 5 and as per RFC2544. The result should be reported as per Section 5 and as per RFC2544.
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. for each of the tested frame sizes.
6.1.5. Throughput for MPLS Label Disposition (PHP) 6.1.5. Throughput for MPLS Label Pop (PHP)
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 pop
disposition (i.e. MPLS to IP) or penultimate hop popping (PHP) (i.e. MPLS to IP) or penultimate hop popping (PHP) using "imp-
using "imp-null" outgoing label. 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 MPLS 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
skipping to change at page 24, line 6 skipping to change at page 24, line 6
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
Please refer to Section 26.2 in RFC2544 in addition to following Please refer to Section 26.2 in RFC2544 in addition to following
the associated procedure for each MPLS forwarding operation in the associated procedure for each MPLS forwarding operation in
accord with the Test Setup described earlier - accord with the Test Setup described earlier -
IP-to-MPLS forwarding (Imposition) Section 6.1.1 IP-to-MPLS forwarding (Push) 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 (Pop) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
MPLS-to-IP forwarding (PHP) Section 6.1.5 MPLS-to-IP forwarding (PHP) Section 6.1.5
Reporting Format Reporting Format
The result should be reported as per Section 5 and as per RFC2544. The result should be reported as per Section 5 and as per RFC2544.
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 (push) or MPLS-to-
MPLS-to-IP (swap) or MPLS-IP (disposition) by the DUT under IP (swap) or MPLS-IP (pop) 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
skipping to change at page 25, line 4 skipping to change at page 25, line 4
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
Please refer to Section 26.3 of RFC 2544 RFC2544 and follow the Please refer to Section 26.3 of RFC 2544 RFC2544 and follow the
associated procedure for each MPLS forwarding operation one-by-one associated procedure for each MPLS forwarding operation one-by-one
in accord with the Test Setup described earlier - in accord with the Test Setup described earlier -
IP-to-MPLS forwarding (Imposition) Section 6.1.1 IP-to-MPLS forwarding (Push) 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 (Pop) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
MPLS-to-IP forwarding (PHP) Section 6.1.5 MPLS-to-IP forwarding (PHP) Section 6.1.5
Reporting Format Reporting Format
The result should be reported as per Section 5 and as per RFC2544. The result should be reported as per Section 5 and as per RFC2544.
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 four MPLS Follow the Test Setup guidelines established for each of five 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
Please refer to Section 26.5 of RFC2544 and follow the associated Please refer to Section 26.5 of RFC2544 and follow the associated
procedure for each MPLS forwarding operation in the referenced procedure for each MPLS forwarding operation in the referenced
Sections one-by-one in accord with the Test Setup described Sections one-by-one in accord with the Test Setup described
earlier - earlier -
IP-to-MPLS forwarding (Imposition) Section 6.1.1 IP-to-MPLS forwarding (Push) 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 (Pop) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
MPLS-to-IP forwarding (PHP) Section 6.1.5 MPLS-to-IP forwarding (PHP) Section 6.1.5
Reporting Format Reporting Format
The result should be reported as per Section 5 and as per RFC2544. The result should be reported as per Section 5 and as per RFC2544.
6.5. Reset 6.5. Reset
Objective Objective
skipping to change at page 26, line 27 skipping to change at page 26, line 27
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.
For this testcase, the requirements of LDP and a routing-protocol For this testcase, the requirements of LDP and a routing-protocol
are removed and replaced by static configurations. For the IP-to- are removed and replaced by static configurations. For the IP-to-
MPLS iteration, static route configurations should be applied. For MPLS iteration, static route configurations should be applied. For
the MPLS-to-MPLS and MPLS-to-IP static label configurations must the MPLS-to-MPLS and MPLS-to-IP static label configurations must
be applied. be applied.
For this test, all graceful-restart features MUST be disabled. For this test, all graceful-restart features MUST be disabled.
Discussion
This test case is intended to provide an insight into how long an
MPLS device could take to be fully operational after any of the
reset events. It is quite likely that the time an IP/MPLS device
takes to become fully operational after any of the reset events
may be different from that of an IP only device. Moreover,
different reset events may produce different results, hence, the
type of reset event performed must be reported with the results.
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 specific Section for procedure (and test Additionally, follow the specific Section for procedure (and test
Setup) for each MPLS forwarding operation one-by-one - Setup) for each MPLS forwarding operation one-by-one -
IP-to-MPLS forwarding (Push) 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 (Pop) Section 6.1.3
MPLS-to-IP forwarding (Aggregate) Section 6.1.4 MPLS-to-IP forwarding (Aggregate) Section 6.1.4
MPLS-to-IP forwarding (PHP) Section 6.1.5 MPLS-to-IP forwarding (PHP) Section 6.1.5
Reporting Format Reporting Format
Same as RFC2544 and the parameters of Section 5 including the Same as RFC2544 and the parameters of Section 5 including the
specific kind of reset performed. specific type of reset performed.
7. Security Considerations 7. Security Considerations
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
skipping to change at page 27, line 36 skipping to change at page 28, line 9
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,
Jeff Byzek, Jay Karthik, Rajiv Pap, Samir Vapiwala, Silvija Andrijic Jeff Byzek, Jay Karthik, Rajiv Papneja, Samir Vapiwala, Silvija
Dry, Scott Bradner, Al Morton and Bill Cerveny for their careful Andrijic Dry, Scott Bradner, Al Morton and Bill Cerveny for their
review and suggestions. careful 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.
 End of changes. 45 change blocks. 
98 lines changed or deleted 104 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/