draft-ietf-bmwg-mpls-forwarding-meth-04.txt   draft-ietf-bmwg-mpls-forwarding-meth-05.txt 
BMWG Aamer Akhter BMWG Aamer Akhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Informational Intended status: Informational
Expires: January 9, 2009 Rajiv Asati Expires: Feb, 2010 Rajiv Asati
Cisco Systems Cisco Systems
Carlos Pignataro Carlos Pignataro
Cisco Systems Cisco Systems
July 9, 2009 August 7, 2009
MPLS Forwarding Benchmarking Methodology for IP Flows MPLS Forwarding Benchmarking Methodology for IP Flows
draft-ietf-bmwg-mpls-forwarding-meth-04.txt draft-ietf-bmwg-mpls-forwarding-meth-05.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
adequate license from the person(s) controlling the copyright in adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than publication as an RFC or to translate it into languages other than
English English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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 9, 2009. This Internet-Draft will expire on Feb 7, 2010.
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 34 skipping to change at page 3, line 34
6.1.1. Throughput for MPLS Label Push............................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 Pop (Unlabeled).................20 6.1.3. Throughput for MPLS Label Pop (Unlabeled).................20
6.1.4. Throughput for MPLS Label Pop (Aggregate).................21 6.1.4. Throughput for MPLS Label Pop (Aggregate).................21
6.1.5. Throughput for MPLS Label Pop (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...........................................28
9. Acknowledgement...............................................28 9. Acknowledgement...............................................28
10. References...................................................29 10. References...................................................29
10.1. Normative References.......................................29 10.1. Normative References.......................................29
10.2. Informative References.....................................29 10.2. Informative References.....................................29
Author's Addresses...............................................30 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
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 - push header and may go through one of three forwarding operations : push
(or LSP ingress), swap or pop (or LSP egress), as defined in (or LSP ingress), swap or pop (or LSP egress), as defined in
[RFC3031]. Such characteristics desire further granularity in MPLS [RFC3031]. Such characteristics desire further granularity in MPLS
forwarding benchmarking than those described in RFC2544. Thus the forwarding benchmarking than those described in 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
skipping to change at page 17, line 19 skipping to change at page 17, line 19
[RFC4928], hence, the usage of ECMP is NOT permitted by this [RFC4928], hence, the usage of ECMP is NOT permitted by this
document to ensure the deterministic forwarding behavior during document to ensure the deterministic forwarding behavior during
the benchmarking. the benchmarking.
Test Procedure Test Procedure
In accord with Section 26 of RFC2544 [RFC2544], the traffic is In accord with Section 26 of RFC2544 [RFC2544], the traffic is
sent from test tool port(s) Ap to the DUT at a constant load for a sent from test tool port(s) Ap to the DUT at a constant load for a
fixed time interval, and is received from the DUT on test tool fixed time interval, and is received from the DUT on test tool
port(s) Bp. The frame may contain either an IP packet or an MPLS port(s) Bp. The frame may contain either an IP packet or an MPLS
packet depending on the testcase need, as described in the Section packet depending on the testcase need, as described in
4.1.4.3. Furthermore, the IP packet must be either an IPv4 or IPv6 Section 4.1.4.3. Furthermore, the IP packet must be either an IPv4
packet, depending on whether the MPLS benchmarking is done for or IPv6 packet, depending on whether the MPLS benchmarking is done
IPv4 or IPv6. for 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 defined as the Throughput in Section 3.17 of through the DUT is defined as the Throughput in Section 3.17 of
[RFC1242] for that test case. Informally, this rate is referred to [RFC1242] for that test case. Informally, this rate is referred to
as the No Drop Rate. as the No Drop Rate.
skipping to change at page 20, line 20 skipping to change at page 20, line 20
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 Pop (Unlabeled) 6.1.3. Throughput for MPLS Label Pop (Unlabeled)
Objective Objective
To obtain the DUT's Throughput (as per RFC 2544) during label pop To obtain the DUT's Throughput (as per RFC 2544) during label pop
or LSP Egress forwaridng operation (i.e. MPLS to IP) using or LSP Egress forwaridng operation (i.e. MPLS to IP) 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 18 skipping to change at page 21, line 18
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 Pop (Aggregate) 6.1.4. Throughput for MPLS Label Pop (Aggregate)
Objective Objective
To obtain the DUT's Throughput (as per RFC 2544) during label pop To obtain the DUT's Throughput (as per RFC 2544) during label pop
or LSP Egress forwarding operation (i.e. MPLS to IP) using or LSP Egress forwarding operation (i.e. MPLS to IP) using
"Aggregate" outgoing label[RFC3031]. ''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 22 skipping to change at page 22, line 22
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 Pop (PHP) 6.1.5. Throughput for MPLS Label Pop (PHP)
Objective Objective
To obtain the DUT's Throughput (as per RFC 2544) during label pop To obtain the DUT's Throughput (as per RFC 2544) during label pop
(i.e. MPLS to IP) or penultimate hop popping (PHP) using "imp- (i.e. MPLS to IP) or penultimate hop popping (PHP) 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 26, line 7 skipping to change at page 26, line 7
MPLS-to-IP forwarding (Pop) 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
Note that BMWG plans to produce a separate document focusing on
'reset' aspects of benchmarking in order to ensure clarity and
consistency in reset procedures beyond what's specified in
RFC2544.
This document does not specify the reset procedures. The text
below describes the MPLS forwarding benchmarking specific setup
that will have to be used in conjuction with the procedures from
the separate document to make this test case meaningful.
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 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
skipping to change at page 26, line 33 skipping to change at page 26, line 43
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 Discussion
This test case is intended to provide an insight into how long an 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 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 reset events. It is quite likely that the time an IP/MPLS device
takes to become fully operational after any of the reset events takes to become fully operational after any of the reset events
may be different from that of an IP only device. Moreover, may be different from that of an IP only device.
different reset events may produce different results, hence, the
type of reset event performed must be reported with the results.
Procedure
Please refer to RFC2544 Section 26.5. Examples of hardware and Modern devices now have many more reset options that were not
software resets are: available when section 26.6 of RFC2544 was published. Moreover,
different reset events on modern devices may produce different
results, hence, needing clarity and consistency in reset
procedures beyond what's specified in RFC2544.
Hardware reset - forwarding module resetting (e.g. OIR). Procedure
Software reset - reset initiated through a CLI (e.g. reload). Please follow the procedure from the separate document for each
MPLS forwarding operation one-by-one -
Additionally, follow the specific Section for procedure (and test
Setup) for each MPLS forwarding operation one-by-one -
IP-to-MPLS forwarding (Push) 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 (Pop) 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 The result should be reported as per section 5 and as per the
specific type of reset performed. separate document.
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 29, line 18 skipping to change at page 29, line 18
[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.
[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 [RFC3031] Rosen et al., ''Multiprotocol Label Switching
Architecture", RFC 3031, August 1999. Architecture'', RFC 3031, August 1999.
[RFC3032] Rosen et al., "MPLS Label Stack Encoding", RFC 3032, [RFC3032] Rosen et al., ''MPLS Label Stack Encoding'', RFC 3032,
January 2001. January 2001.
[RFC3107] Rosen, E. and Rekhter, Y., "Carrying Label Information in [RFC3107] Rosen, E. and Rekhter, Y., ''Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4'', RFC 3107, May 2001.
[RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and [RFC5036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
B. Thomas, "LDP Specification", RFC 5036, January 2001. B. Thomas, "LDP Specification", RFC 5036, January 2001.
10.2. Informative References 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.
[RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, Dec 2001. Tunnels", RFC 3209, Dec 2001.
[RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private [RFC4364] Rosen E. and Rekhter Y., "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC4364, February 2006. Networks (VPNs)", RFC4364, February 2006.
[RFC4271] Rekhter, Y. and T. Li, "Framework for Layer 2 Virtual [RFC4271] Rekhter, Y. and T. Li, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, Sep 2006. Private Networks (L2VPNs)'', RFC 4664, Sep 2006.
[RFC4664] Rosen, E. and Andersson L., " A Border Gateway Protocol 4 [RFC4664] Rosen, E. and Andersson L., " A Border Gateway Protocol 4
(BGP-4)", RFC 4271, Jan 2006. (BGP-4)'', RFC 4271, Jan 2006.
[IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges", [IEE8021] Mick Seaman (editor), "IEEE Std 802.1D-2004, MAC Bridges",
Feb 2004. Feb 2004.
[IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society, [IEE8023] LAN/MAN Standards Committee of the IEEE Computer Society,
"IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple "IEEE Std 802.3as-2006, Part 3: Carrier Sense Multiple
Access with Collision Detection (CSMA/CD) Access Method Access with Collision Detection (CSMA/CD) Access Method
and Physical Layer Specifications, Amendment 3: Frame and Physical Layer Specifications, Amendment 3: Frame
format extensions", Nov 2006. format extensions", Nov 2006.
[RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing
in MPLS Networks", RFC3443, Jan 2003. in MPLS Networks", RFC3443, Jan 2003.
[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 [RFC4090] Pan, et al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC4090, May 2005. Tunnels", RFC4090, May 2005.
Author's Addresses Author's Addresses
Aamer Akhter Aamer Akhter
 End of changes. 25 change blocks. 
36 lines changed or deleted 45 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/