zafar ali (zali@cisco) tomohiro otani ([email protected])
DESCRIPTION
Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt. Zafar Ali ([email protected]) Tomohiro Otani ([email protected]). LSP. 10.1.1.2. 10.1.1.3. Router 1. OXC2. Ethernet IF. OXC1. OXC3. Ethernet IF. - PowerPoint PPT PresentationTRANSCRIPT
167th IETF, San Diego, November 200667th IETF, San Diego, November 2006
Address Resolution for GMPLS controlled PSC Ethernet Interfaces
draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt
Zafar Ali ([email protected])Tomohiro Otani ([email protected])
22267th IETF, San Diego, November 200667th IETF, San Diego, November 2006
Scope of the Draft
• Issues with the use of ARP over GMPLS controlled Ethernet router-to-router (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.
OXC2
Router 1
Router 2
Non-Ethernet GMPLS Network
OXC3
OXC1
OXC4
LSP10.1.1.2 10.1.1.3
Ethernet IF
Ethernet IF
33367th IETF, San Diego, November 200667th IETF, San Diego, November 2006
Inter-op Issues in resolving ARP
• 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 end-points. 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: Agree on a common understanding.
OXC2Router 1
Router 2
OXC3
OXC1
OXC4
LSP10.1.1.2 10.1.1.3
10.1.1.4
20.1.1.1
20.1.1.210.1.1.1
Non-Ethernet GMPLS Network
44467th IETF, San Diego, November 200667th IETF, San Diego, November 2006
ARP Round-trip Delay
• 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, 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.
OXC2
Router 1
Router 2
OXC3
OXC1 OXC4
LSP1
LSP2
E1/0
E2/0
Working LSP
Protecting LSP
Non-Ethernet GMPLS Network
E2/0
E1/0
55567th IETF, San Diego, November 200667th IETF, San Diego, November 2006
Proposed Solution
• The draft proposes a subobject (END_POINT_MAC_ADDR) to be carried in Path and Resv message to learn Ingress and Egress MAC addresses, respectively.
• END_POINT_MAC_ADDR is of type 11bbbbbb
• The Ingress LSR puts the MAC address of its outgoing physical interface in the Path message.
• When the Egress Router receives a Path message with the END_POINT_MAC_ADDR object, it adds END_POINT_MAC_ADDR object to the Resv message and puts the MAC address of incoming physical interface.
OXC2Router 1
Router 2
Non-Ethernet GMPLS Network
OXC3
OXC1
OXC4
10.1.1.2 10.1.1.3
E1/0
Ethernet IF
Path: MAC: 01-23-45-fe-dc-ba
Resv: MAC: ab-cd-ef-54-32-10
66667th IETF, San Diego, November 200667th IETF, San Diego, November 2006
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