1 / 6

Zafar Ali (zali@cisco) Tomohiro Otani (otani@kddilabs.jp)

Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt. Zafar Ali (zali@cisco.com) Tomohiro Otani (otani@kddilabs.jp). LSP. 10.1.1.2. 10.1.1.3. Router 1. OXC2. Ethernet IF. OXC1. OXC3. Ethernet IF.

luke
Download Presentation

Zafar Ali (zali@cisco) Tomohiro Otani (otani@kddilabs.jp)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Address Resolution for GMPLS controlled PSC Ethernet Interfacesdraft-ali-arp-over-gmpls-controlled-ethernet-psc-i-02.txt Zafar Ali (zali@cisco.com) Tomohiro Otani (otani@kddilabs.jp)

  2. LSP 10.1.1.2 10.1.1.3 Router 1 OXC2 Ethernet IF OXC1 OXC3 Ethernet IF Non-Ethernet GMPLS Network Router 2 OXC4 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. 67th IETF, San Diego, November 2006

  3. 20.1.1.1 LSP 10.1.1.2 10.1.1.3 Router 1 OXC2 20.1.1.2 10.1.1.1 OXC1 OXC3 Non-Ethernet GMPLS Network 10.1.1.4 Router 2 OXC4 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. 67th IETF, San Diego, November 2006

  4. E1/0 OXC2 Non-Ethernet GMPLS Network Working LSP LSP1 Router 1 OXC3 LSP2 E1/0 E2/0 OXC1 OXC4 Protecting LSP Router 2 E2/0 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. 67th IETF, San Diego, November 2006

  5. Proposed Solution Path: MAC: 01-23-45-fe-dc-ba • 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. 10.1.1.2 10.1.1.3 Router 1 OXC2 E1/0 Resv: MAC: ab-cd-ef-54-32-10 OXC1 OXC3 Ethernet IF Non-Ethernet GMPLS Network Router 2 OXC4 67th IETF, San Diego, November 2006

  6. 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 Thank You 67th IETF, San Diego, November 2006

More Related