Internet Draft Zafar Ali
Cisco Systems
Tomohiro Otani
KDDI R&D Laboratories, Inc.
Document: draft-ali-arp-over-gmpls-
controlled-ethernet-psc-if-00.txt
Expires: April 2006 October 2005
Address Resolution for GMPLS controlled PSC Ethernet Interfaces
draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document outlines some 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. The document also
proposes solutions accordingly.
Conventions used in this document
Ali, Z., Otani, T.
[Page 1]
draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction...................................................2
2. END_POINT_COMP_LINK_IP_ADDR Object.............................3
3. END_POINT_MAC_ADDR Object......................................4
4. Security Considerations........................................4
5. IANA Considerations............................................4
6. Intellectual Property Considerations...........................4
7. References.....................................................5
7.1 Normative Reference........................................5
7.2 Informative Reference......................................5
8. Author's Addresses.............................................6
9. Full Copyright Statement.......................................6
1.
Introduction
This draft address the scenario where edge routers are connected via
a non-Ethernet switch capable GMPLS core, e.g., FSC or LSC core.
Furthermore, the interfaces between the router and the optical device
(OXC) are Ethernet.
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. This information
needs to be re-learned, every time the path taken by the GMPLS LSP
changes (e.g., due to re-routing or re-optimization).
Knowledge of IP address of the first component link in the route (at
the Ingress Router) and the IP address of the last component link in
the route (at the Egress router) is required to run ARP over the
GMPLS LSP. If ERO is strict, and the last TE link in the route is
unbundled, Ingress Router can use the computed route to find the
address of the last TE link in the route. However, we cannot assume
that ERO is strict or the TE link are unbundled. Similarly, the
Egress router can use RRO to find the address of the first component
link in the route, if the first TE link in the route is unbundled.
However, use of RRO is optional.
This document proposes an optional RSVP object
(END_POINT_COMP_LINK_IP_ADDR) to carry the IP address of the first
component link in the path in the Path message, and the IP address of
Ali, Z., Otani, T.
[Page 2]
draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005
the last component link in the route in the Resv message. These
addresses can then be use to resolve MAC addresses at the two end of
the LSP.
This draft also addresses latency associated with running ARP over
GMPLS controlled Ethernet interfaces. Such latency adds to the
traffic switchover delay and consequently traffic loss for 1:1
protected LSP without extra traffic, or when LSP route changes due to
due to re-routing (restoration) or re-optimization, etc. Consequently
This document also proposes an optional RSVP object
(END_POINT_MAC_ADDR) to carry hardware addresses at the two end of
the LSP, in the Path and Resv messages. If END_POINT_MAC_ADDR Object
is used, END_POINT_COMP_LINK_IP_ADDR object is not required.
2.
END_POINT_COMP_LINK_IP_ADDR Object
The END_POINT_COMP_LINK_IP_ADDR object has a class number TBA by IANA
(of type 11bbbbbb), C-Type of TBD and length of 8. The format is
given below. The object can easily be extended for IPv6 addresses
(TBD).
Figure 1: END_POINT_COMP_LINK_IP_ADDR Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component Link IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message.
When the first component link in the route (hosted by the Ingress
Router) is numbered, the Ingress LSR puts the IP address of the
component link in the Path message. If this TE link is unbundled, the
address is the address of the TE link in question. If the component
link is unnumbered, the node id of the Ingress router is carried in
the END_POINT_COMP_LINK_IP_ADDR Object.
When the Egress Router receives a Path message with the
END_POINT_COMP_LINK_IP_ADDR object, it adds
END_POINT_COMP_LINK_IP_ADDR object to the Resv message. When the last
component link in the route (hosted by the Egress Router) is numbered,
the Egress LSR puts the IP address of the component link in the Resv
message. If this TE link is unbundled, the address is the address of
the TE link in question. If the component link is unnumbered, the
node id of the Ingress router is carried in the
END_POINT_COMP_LINK_IP_ADDR Object.
Ali, Z., Otani, T.
[Page 3]
draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005
3.
END_POINT_MAC_ADDR Object
The END_POINT_MAC_ADDR object has a class number TBA by IANA (of type
11bbbbbb), C-Type of TBD and length of 28. The format is given below.
Figure 1: END_POINT_MAC_ADDR Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| End Point' MAC Address |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object can optionally appear in either a Path message or a Resv
message.
The Ingress LSR puts the MAC address of the first component link in
the route (hosted by the Ingress Router) 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 the last component link in the route, which
is host by it (Egress Router).
4.
Security Considerations
This document does not introduce new security issues. The security
considerations pertaining to the original RSVP protocol [RFC2205]
remain relevant.
5.
IANA Considerations
Type of RSVP Object proposed in this document needs to be assigned.
6.
Acknowledgements
The author would like to acknowledge close discussions on this topic
with Adrian Farrel and Dan Tappan.
7.
Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Ali, Z., Otani, T.
[Page 4]
draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8.
References
8.1
Normative Reference
[RFC2205] "Resource ReSerVation Protocol (RSVP) - Version 1,
Functional Specification", RFC 2205, Braden, et al, September 1997.
[RFC3209] "Extensions to RSVP for LSP Tunnels", D. Awduche, et al,
RFC 3209, December 2001.
[BUNDLE] "Link Bundling in MPLS Traffic Engineering", draft-ietf-
mpls-bundle-06.txt, K. Kompella, et al, January 2003.
[RFC3471] Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description, RFC 3471, L. Berger, et al,
January 2003.
[RFC3473] "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-
TE) Extensions", RFC 3473, L. Berger, et al, January 2003.
[RFC3477] "Signaling Unnumbered Links in Resource ReSerVation
Protocol - Traffic Engineering (RSVP-TE) ", RFC 3477, K. Kompella,
Y. Rekhter, January 2003.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119, S. Bradner, March 1997.
8.2
Informative Reference
[ARP] "An Ethernet Address Resolution Protocol ", RFC 826, 1982.
Ali, Z., Otani, T.
[Page 5]
draft-ali-arp-over-gmpls-controlled-ethernet-psc-if-00.txt Oct. 2005
9.
Author's Addresses
Zafar Ali
Cisco Systems Inc.
2000 Innovation Dr.,
Kanata, Ontario, K2K 3E8
Canada.
Phone: (613) 889-6158
Email: zali@cisco.com
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Kamifukuoka
Saitama, 356-8502. Japan
Phone: +81-49-278-7357
Email: otani@kddilabs.jp
10.
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Ali, Z., Otani, T.
[Page 6]