Transcript PPT Version

Address Resolution for GMPLS controlled
PSC Ethernet Interfaces
draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-03.txt
Zafar Ali ([email protected])
Hassan Sheikh ([email protected])
Tomohiro Otani ([email protected])
68th IETF, Prague, March 2007
1
Agenda
• How comments from CCAMP meeting at last IETF
are addressed?
• Summary of recommendations proposed.
• Next Steps.
68th IETF, Prague, March 2007
2
Changes from the last revision
• Summary of the minutes of CCAMP meeting at IETF 67
(http://www3.ietf.org/proceedings/06nov/minutes/ccamp.html)
 Agree on defining a common addressing scheme for ARP
Resolution.
 No extension to RSVP-TE for this purpose.
• The new version has been updated accordingly.
68th IETF, Prague, March 2007
3
Scope of the Draft
LSP
10.1.1.2
Router 1
10.1.1.3
OXC2
Ethernet IF
OXC1
OXC3
Non-Ethernet
GMPLS Network
Ethernet IF
Router 2
OXC4
• Issues with the use of ARP over GMPLS controlled Ethernet router-torouter (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC
or LSC GMPLS core.
• When an LSP Path is established between the Ingress Router to
Egress Router, Ethernet interface at the two routers comes up.
However, before this LSP (or interface) can forward any IP traffic, MAC
address of the remote router needs to be learned.
• Point-to-point Ethernet Interfaces.
68th IETF, Prague, March 2007
4
Inter-op Issues in resolving ARP
20.1.1.1
LSP
10.1.1.2
Router 1
10.1.1.3
OXC2
10.1.1.1
20.1.1.2
OXC1
OXC3
Non-Ethernet
GMPLS Network
10.1.1.4
Router 2
OXC4
• Inter-op issues in resolving ARP among vendors found at various
public events/ private testing efforts.
 Some routers send ARP request for the address of the TE link at the
end-point.
 Some LSRs send ARP request using the tunnel IF address at the endpoints.
 Some vendors do not reply to ARP request sent to the loopback
address. Also, should the loopback interface address from optical or
packet instance be use.
• Solution: At last IETF meeting we agreed to define a common
addressing scheme for ARP Resolution.
68th IETF, Prague, March 2007
5
Addressing Scheme for ARP Resolution
20.1.1.1
LSP
10.1.1.2
Router 1
10.1.2.1
OXC2
20.1.1.2
10.1.1.1
OXC1
OXC3
Non-Ethernet
GMPLS Network
10.1.2.2
Router 2
OXC4
• An LSR SHOULD use tunnel interface address for ARP
request.
 This would also address the issue associated with the use of
disjoint subnets used with numbered TE links between the
Ingress LSR and the Optical node, and the Egress LSR and the
optical node.
• An LSR, based on a local decision, can determine if the
Interface is point-to-point and SHOULD resolve APR using
loopback addresses.
68th IETF, Prague, March 2007
6
ARP Round-trip Delay
E1/0
Router 1
OXC2
LSP1
Non-Ethernet
GMPLS Network
Working LSP
OXC3
LSP2
E2/0
OXC1
Protecting LSP
E1/0
OXC4
E2/0
Router 2
• ARP round-trip delay before traffic can be forwarded to the
protecting LSP, when doing a cutover to a "cold standby" LSP (e.g.,
1:1 Case).
 In 1:1 or 1:N protection without extra traffic, the protecting LSP
cannot carry any traffic until the traffic is switchover.
• End-point MAC address needs to be re-learned once the ARP cache
entries time-out, or every time the path taken by the GMPLS LSP
changes (e.g., due to re-routing or re-optimization).
• The Round Trip latency implies traffic loss (i.e., no O(50 msec)
guarantees).
68th IETF, Prague, March 2007
7
Addressing ARP Round-trip Delay Issue for
Protected tunnels
E1/0
Router 1
OXC2
LSP1
Non-Ethernet
GMPLS Network
Working LSP
OXC3
LSP2
E2/0
OXC1
Protecting LSP
E1/0
OXC4
E2/0
Router 2
• Enable ARP learning for protecting LSP ahead of
time.
• The ARP cache SHOULD NOT timeout the ARP
entry on both the working and the protecting LSPs.
68th IETF, Prague, March 2007
8
Next Steps
• We would like to see WG feedback on this Document.
• We would like to request WG to accept this ID as a WG
document.
68th IETF, Prague, March 2007
9