1. 1 68th IETF, Prague, March 2007 Address Resolution for GMPLS controlled PSC Ethernet Interfaces draft-ali-arp-over-gmpls-controlled-ethernet-psc-i-04.txt Zafar Ali (zali@cisco.com) Hassan Sheikh (hassans@cisco.com) Tomohiro Otani (otani@kddilabs.jp)

2. 222 68th IETF, Prague, March 2007 Agenda How comments are addressed? Summary of proposed recommendations. Next Steps.

3. 333 68th IETF, Prague, March 2007 Change History Summary of the minutes of CCAMP meeting at IETF 67 (http://www3.ietf.org/proceedings/06nov/minutes/ccamp.html)  Agreed on defining a common addressing scheme for ARP Resolution.  No extension to RSVP-TE for this purpose. The version 03 was updated accordingly. Version 04 addresses comments received from CCAMP meeting at IETF 68.

4. 444 68th IETF, Prague, March 2007 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. In this case, GMPLS LSP is using Ethernet encoding. 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 LSP 10.1.1.210.1.1.3 Ethernet IF Non-Ethernet IF

5. 555 68th IETF, Prague, March 2007 ARP resolution on GMPLS LSP using Eth framing Router # 1 Router # 2 192.168.1.1/29192.168.1.2/29 ARP reuest ARP response Send L3 packet to router # 2 GMPLS LSP Eth link OXC Router # 1 needs to send packet to Router # 2. The following information is required: (1) SRC IP address (2) DST IP address (3) SRC MAC and (4) DST MAC. Step # 2 - Router # 1 knows (1), (2) and (3) but does not know (4). It needs to associate L3 Network Layer with L2 data link layer address, i.e., need DST MAC address to send the packet to Router #2. Step # 1 - Router # 1 sends out an ARP query requesting the MAC address corresponding to the IP address 192.168.1.2. Step # 3 - Router # 2 responds with the MAC address as the IP address is local to router # 2 Step # 4 - Step # 5 - Router # 1 now knows (1), (2), (3) and (4) from step # 1. It can send L3 traffic to router # 2 now

6. 666 68th IETF, Prague, March 2007 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: At IETF 67 meeting we agreed to define a common addressing scheme for ARP Resolution. An LSR SHOULD use address from packet network (and not the TE link address of the optical link) for ARP request. OXC2 Router 1 Router 2 OXC3 OXC1 OXC4 LSP 10.1.1.210.1.1.3 10.1.1.4 192.168.1.1/29 192.168.1.2/29 10.1.1.1 Non-Ethernet GMPLS Network

7. 777 68th IETF, Prague, March 2007 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 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). Solution: Assign stable virtual MAC address that can share with the both Ethernet IF (protection and working). 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

8. 888 68th IETF, Prague, March 2007 Next Steps We need to do a revision based on the comments received.

9. 9 68th IETF, Prague, March 2007 Backup Slides

10. 10 68th IETF, Prague, March 2007 Why not use gratuitous ARP ?? Router # 1 Router # 2 192.168.1.1/29192.168.1.2/29 Gratuitous ARP could mean both gratuitous ARP request or gratuitous ARP reply. Gratuitous in this case means a request/reply that is not normally needed according to the ARP specification (RFC 826) but could be used in some cases. A gratuitous ARP request is an Address Resolution Protocol request packet where the source and destination IP are both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff. Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts. Pros – Automatic Detection of MAC address of the remote node (in p2p) and/or link up down event. Cons – For GMPLS we have seen that this mechanism is unreliable because: Transmitted once only so if missed – will not be sent again. We have seen cases in our testing where one side know the MAC address of the other side but the other side does not know anything as it missed out the gratuitous ARP sent to it. Issue when ARP cache times out e.g. in case there is no activity on the data link. P&R protection LSP is the perfect example of a GMPLS application where this is seen. ARP reuest ARP response GMPLS LSP Eth link OXC