Download mpls-4

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Net bias wikipedia , lookup

Distributed firewall wikipedia , lookup

Airborne Networking wikipedia , lookup

Peering wikipedia , lookup

Deep packet inspection wikipedia , lookup

Lag wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Network tap wikipedia , lookup

Serial digital interface wikipedia , lookup

Dijkstra's algorithm wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Transcript
Operations and Maintenance Next
Generation Requirements
draft-amante-oam-ng-requirements-01
Shane Amante
Alia Atlas
Andrew Lange
Danny McPherson
March 10, 2008
Overview
Why use LAG, ECMP?
 Background
 Use Cases
 Intra- vs. Inter-AS OAM Requirements
 Path Capabilities

Why use LAG, ECMP?
LAG, ECMP and ECMP over LAG are
used to increase virtual bandwidth
between two, or more, [adjacent] nodes.
 Why not just use larger links (e.g.: 40G,
100G) and avoid these problems?

– Because the problems discussed in this
draft still exist with N x 40G, N x 100G, etc.
Background & Goals

Inspired by: draft-atlas-icmp-unnumbered
–

This memo defines ICMP extensions through which an router or host can explicitly identify
the interface upon which an undeliverable datagram arrived. The incoming interface can
be identified by ifIndex, name, and/or address. The extensions defined herein are
particularly useful when troubleshooting networks with unnumbered interfaces, parallel
interfaces and/or asymmetric routing.
Goal: Specify requirements to enhance IP & MPLS
traceroute and ping to identify and exercise specific
paths through links consisting of LAG, ECMP and
ECMP over LAG.
– i.e., update traceroute/ping for the 21st century.

Prefer one solution, which addresses:
– Intra-AS: Lots of information returned to originator
– Inter-AS: Limited/Select information returned to originator
Scenario 1: Traceroute thru Routed Hops
LAG-1
LAG-2
Intf-2: 10.1.1.2/30
R1
A1
A2
B1
B2
C1
C2
Intf-1: 10.1.1.1/30

Intf-4: 10.5.1.2/30
D1
D2
R2
R3
E1
E2
Intf-3: 10.5.1.1/30
During traceroute from R1 to R3, need to
know:
– Actual component-links used on output and
input for a particular user’s microflow. If no
response from R3, want to know output
component-link used by R2 to get to R3.

If using “legacy” ping, from R1 to R3, it is not
guaranteed to be hashed onto same LAG or
ECMP component-links as end-user traffic.
Scenario 2: Traceroute thru 1 Switched Hop
LAG-1
LAG-2
Intf-2: 10.1.1.2/30
A1
A2
R1
SW1
B1
B2
C1
C2
D1
D2
E1
E2
R2
Intf-1: 10.1.1.1/30

Mostly the same as Scenario 1, except
puts more emphasis on the need to:
– Have R1 return outgoing component-link
ID, in cases where SW1 dies.
– In addition, because SW1 makes an
independent hashing decision on IP/MPLS
packets need R2 to return incoming
component-link ID.
Scenario 3: Traceroute thru 2+ Switched Hops
LAG-1
LAG-2
LAG-3
Intf-2: 10.1.1.2/30
A1
A2
R1
C1
C2
SW1
B1
B2
SW2
D1
D2
E1
E2
F1
F2
G1
G2
R2
Intf-1: 10.1.1.1/30




Scenario common in Enterprise or DataCenter
environments.
SW1 & SW2 commonly understand how to loadhash based on outer IP and/or MPLS payloads to
make effective use of bandwidth between them.
“Legacy” traceroute is ineffective because you will not
know the identity of component-links between SW1
<-> SW2.
“Legacy” ping is ineffective because traffic is not
guaranteed to use component-links as end-user
traffic between SW1 <-> SW2 <-> R2.
Other scenarios

ECMP: TBD
 Proxy Traceroute/Ping:
– Need for functionality similar to draft-ietf-mplsremote-lsp-ping
– PTR/PTP are important, in order to scale
automated performance monitoring of larger
networks.

Performance Monitoring
– Used for automatically & proactively detecting
(soft) failures in the network.
– Discuss differences between:
• Proactive Periodic Perf. Monitoring
• Proactive Perpetual Perf. Monitoring
Intra-AS OAM Reqmt’s

Must work with IP and MPLS
 Traceroute Probe Requests:
– Ability to specify input “keys” to hash/ECMP algorithm, (e.g.: 5-tuple for IP),
in probe payload to exercise hash algorithm with ‘real’ customer traffic.

Traceroute Probe Replies:
–
–
–
–
–
Incoming Interface Name (+ Descr)
Outgoing Interface Name (+ Descr)
# of component-links in a bundle
% BW Utilization on interface(s)
Remote Link-Layer neighbor name + Interface Name
• Required for automatically identifying Layer-2 switched hops

Ping
– Ability to input “keys” to hash/ECMP algorithm, (e.g.: 5-tuple for IP), in
probe payload to exercise hash algorithm with ‘real’ customer traffic.
– MUST follow data plane for forwarding within the network elements.

Proxy Traceroute/Ping Support
– Used by Network Monitoring systems to proactively exercise paths through
network similar to MPLS LSR self-test.

Need some form of (lightweight) authentication for Intra-AS OAM to
only reveal detailed network knowledge to “trusted” entities.
– Also, recommend that dropping OAM packets may be necessary to prevent
starvation of resources within network elements.
Inter-AS OAM Reqmt’s

Must work with IP and MPLS
– For example: customer & peering links

Traceroute Probe Requests:
– Ability to specify input “keys” to hash/ECMP algorithm, (e.g.:
5-tuple for IP), in probe payload to exercise hash algorithm
with ‘real’ customer traffic.

Traceroute Probe Replies:
– Incoming Interface Name
– Outgoing Interface Name

Ping
– Ability to specify input “keys” to hash/ECMP algorithm, (e.g.:
5-tuple for IP), in probe payload to exercise hash algorithm
with ‘real’ customer traffic.
Path Capabilities
Probe before traceroute? Or,
 Designate special label/codepoint for
“new” OAM protocol?
 Draft currently recommends latter
approach to deterministically deal with
cases of oscillating links and/or paths.

Comments? Questions?