< draft-ietf-isis-igp-p2p-over-lan-03.txt   draft-ietf-isis-igp-p2p-over-lan-04.txt >
Network Working Group Naiming Shen
Internet Draft Acee Lindem Network Working Group Naiming Shen, Ed (Redback Networks)
Expiration Date: February 2004 Jenny Yuan Internet Draft Alex Zinin, Ed (Alcatel)
File name: draft-ietf-isis-igp-p2p-over-lan-03.txt Redback Networks Expiration Date: January 2005
Alex Zinin July 2004
Alcatel
Russ White
Stefano Previdi
Cisco Systems
August 2003
Point-to-point operation over LAN Point-to-point operation over LAN
in link-state routing protocols in link-state routing protocols
draft-ietf-isis-igp-p2p-over-lan-03.txt draft-ietf-isis-igp-p2p-over-lan-04.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as Drafts as reference material or to cite them other than as
skipping to change at page 2, line 5 skipping to change at page 2, line 5
Abstract Abstract
The two predominant circuit types used by link state routing The two predominant circuit types used by link state routing
protocols are point-to-point and broadcast. It is important to protocols are point-to-point and broadcast. It is important to
identify the correct circuit type when forming adjacencies, identify the correct circuit type when forming adjacencies,
flooding link state database packets, and representing the circuit flooding link state database packets, and representing the circuit
topologically. This document describes a simple mechanism to treat topologically. This document describes a simple mechanism to treat
the broadcast network as a point-to-point connection from the the broadcast network as a point-to-point connection from the
standpoint of IP routing. standpoint of IP routing.
Contributors
The following individuals are the authers that contributed to the
contents of this document.
Acee Lindem
Redback Networks
102 Carric Bend Court
Cary, NC 27519 USA
acee@redback.com
Jenny Yuan
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
jenny@redback.com
Russ White
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
e-mail: riw@cisco.com
Stefano Previdi
Cisco Systems, Inc.
De Kleetlaan 6A
1831 Diegem - Belgium
email: sprevidi@cisco.com
1. Introduction 1. Introduction
Point-to-point and broadcast are the two predominant circuit Point-to-point and broadcast are the two predominant circuit
types used by link state routing protocols such as ISIS [ref1] types used by link state routing protocols such as ISIS [ref1]
[ref2] and OSPF [ref3]. They are treated differently with respect [ref2] and OSPF [ref3, ref5]. They are treated differently with
to establishing neighbor adjacencies, flooding link-state respect to establishing neighbor adjacencies, flooding link-state
information, representation of the topology, SPF calculation and information, representation of the topology, SPF calculation and
protocol packets. The most important differences are that broadcast protocol packets. The most important differences are that broadcast
circuits utilize the concept of a designated router and are circuits utilize the concept of a designated router and are
represented topologically as virtual nodes in the network topology represented topologically as virtual nodes in the network topology
graph. graph.
Compared with broadcast circuits, point-to-point circuits Compared with broadcast circuits, point-to-point circuits
afford more straightforward IGP operation. There is no designated afford more straightforward IGP operation. There is no designated
router involved and there is no representation of the pseudo-node router involved and there is no representation of the pseudo-node
or network LSA in the link state database. For ISIS, there also is or network LSA in the link state database. For ISIS, there also is
skipping to change at page 3, line 15 skipping to change at page 3, line 44
Also, if a broadcast segment wired as a point-to-point link Also, if a broadcast segment wired as a point-to-point link
can be treated as a point-to-point link, only the connection between can be treated as a point-to-point link, only the connection between
the two routers would need to be advertised as a topological entity. the two routers would need to be advertised as a topological entity.
Even when there are multiple routers on the LAN an ISP may want Even when there are multiple routers on the LAN an ISP may want
to sub-group the routers into multiple vLANs since this allows to sub-group the routers into multiple vLANs since this allows
them to assign different costs to IGP neighbors. When there are them to assign different costs to IGP neighbors. When there are
only two routers in some of the vLANs, this LAN can be viewed by only two routers in some of the vLANs, this LAN can be viewed by
the IGP as a mesh of point-to-point connections. the IGP as a mesh of point-to-point connections.
As a side benefit, unnumbered interface can also be applied over IP unnumbered configuration is widely used in networks. It enables
p2p-over-lan circuits. The advantages of unnumbered point-to-point IP processing on a point-to-point interface without an explicit
links are obvious in the current IP addressing environment where IP address. The IP unnumbered interface can "borrow" the IP
addresses are a scarce resource. Separating the concept of network address of another interface on the node. The advantages of
type from media type will allow LANs, e.g. ethernet, to be unnumbered point-to-point links are obvious in the current IP
unnumbered and realize the IP address space savings. Another addressing environment where addresses are a scarce resource. The
advantage is in simpler network management and configuration. unnumbered interface can also be applied over p2p-over-lan circuits.
Separating the concept of network type from media type will allow
LANs, e.g. ethernet, to be unnumbered and realize the IP address
space savings. Another advantage is in simpler network management
and configuration. In the case of IPv6 network, link-local address
used in ISIS [ref4] and OSPFv3 [ref5] serves the same purpose.
3. IP multi-access subnets 3. IP multi-access subnets
When an IP network includes multi-access segments, each segment is When an IP network includes multi-access segments, each segment is
usually assigned a separate subnet and each router connected to it is usually assigned a separate subnet and each router connected to it is
assigned a distinct IP address within that subnet. The role of the assigned a distinct IP address within that subnet. The role of the
IP address assigned to a multi-access interface can be outlined as IP address assigned to a multi-access interface can be outlined as
follows: follows:
1. Source IP address - The interface address can be used by 1. Source IP address - The interface address can be used by
skipping to change at page 4, line 32 skipping to change at page 5, line 18
In order to allow LAN links used to connect only two routers to be In order to allow LAN links used to connect only two routers to be
treated as unnumbered point-to-point interfaces, the MAC address treated as unnumbered point-to-point interfaces, the MAC address
resolution and nexthop IP address issues need to be addressed. resolution and nexthop IP address issues need to be addressed.
4.1 Operation of ISIS 4.1 Operation of ISIS
This p2p-over-lan circuit extension for ISIS is only concerned This p2p-over-lan circuit extension for ISIS is only concerned
in pure IP routing and forwarding operation. in pure IP routing and forwarding operation.
Since the physically circuit is a broadcast one, the ISIS protocol Since physically the circuit is a broadcast one, the ISIS protocol
packets need to have MAC addresses for this p2p-over-lan circuit. packets need to have MAC addresses for this p2p-over-lan circuit.
From link layer point of view, those packets are ISIS LAN packets. From link layer point of view, those packets are ISIS LAN packets.
The Multi-destination address including AllISs, AllL1ISs and AllL2ISs The Multi-destination address including AllISs, AllL1ISs and AllL2ISs
defined in [ref1] can be used for link layer encapsulation, the defined in [ref1] can be used for link layer encapsulation, the
use of AllISs is recommended. use of AllISs is recommended.
The circuit needs to have IP address(es) and the p2p IIH over this The circuit needs to have IP address(es) and the p2p IIH over this
circuit MUST include the IP interface address(es) as defined in circuit MUST include the IP interface address(es) as defined in
[ref2]. The IP address(es) can be numbered or unnumbered. [ref2]. The IPv4 address(es) included in the IIHs is either the
IP address assigned to the interface in the case of a numbered
4.2 Operation of OSPF interface or the interface-independent IP address in the case of
an unnumbered interface. The IPv6 addresses are link-local IPv6
address(es) [ref4].
OSPF routers supporting the capabilities described herein should 4.2 Operation of OSPF and OSPFv3
support an additional interface configuration parameter specifying
the interface topology type. For a LAN (i.e., broadcast capable)
interface, the interface may be viewed as a point-to-point interface.
Both routers on the LAN will simply join the AllSPFRouters
(224.0.0.5) multicast group and send all OSPF packets to 224.0.0.5.
This is identical to operation over a physical point-to-point link
as described in sections 8.1 and 8.2 of [ref3].
4.3 IP forwarding and ARP OSPF and OSPFv3 [ref5] routers supporting the capabilities
described herein should support an additional interface
configuration parameter specifying the interface topology type.
For a LAN (i.e., broadcast capable) interface, the interface may
be viewed as a point-to-point interface. Both routers on the LAN
will simply join the AllSPFRouters multicast group and send all
OSPF packets with a destination address of AllSPFRouters.
AllSPFRouters is 224.0.0.5 for OSPF and FF02::5 for OSPFv3.
This is identical to operation over a physical point-to-point
link as described in sections 8.1 and 8.2 of [ref3].
Unlike normal point-to-point IGP circuit, the IP nexthop for the 4.3 ARP and ND
routes using this p2p-over-lan circuit as an outbound interface is
not optional. The IP nexthop address has to be a valid interface
or internal address on the adjacent router. This address is used by
local router to obtain the MAC address for IP packet forwarding.
Proxy ARP has to be enabled if the address is not the adjacent
interface IP address.
In the case where unnumbered IP addresses are used for p2p-over-lan Unlike normal point-to-point IGP circuit, the IP nexthop for the
circuit, the source IP address of ARP request and the target routes using this p2p-over-lan circuit as an outbound interface is
interface IP address are usually on different subnets. The ARP not optional. The IP nexthop address has to be a valid interface
should reply if this is a p2p-over-lan circuit, or an or internal address on the adjacent router. This address is used by
implementation MAY choose to limit the reply to the case where the local router to obtain the MAC address for IP packet forwarding.
IGP peer is requesting over this unnumbered p2p-over-lan circuit. The ARP process has to be able to resolve the internal IP address
used for the unnumbered p2p-over-lan circuits. In IPv6 case,
the ND resolves the MAC for the link-local address on the
p2p-over-lan circuit, which is part of the IPv6 neighbor
discovering process [ref6].
4.4 Other MAC address resolution mechanisms 4.4 Other MAC address resolution mechanisms
In more general cases while p2p-over-lan circuit is used as an In more general cases while p2p-over-lan circuit is used as an
unnumbered link, other MAC address resolution mechanisms are needed unnumbered link, other MAC address resolution mechanisms are needed
for IP packet forwarding. For example, if link-state IGP is not for IP packet forwarding. For example, if link-state IGP is not
configured over this p2p-over-lan link, or if the mechanism described configured over this p2p-over-lan link, or if the mechanism described
in section 4.3 is not possible. The following techniques can be used in section 4.3 is not possible. The following techniques can be used
to acquire the MAC address and/or the next-hop IP address of the to acquire the MAC address and/or the next-hop IP address of the
remote device on an unnumbered point-to-point LAN link. remote device on an unnumbered point-to-point LAN link.
1. Static configuration. A router can be statically configured 1. Static configuration. A router can be statically configured
with the MAC address that should be used as the destination with the MAC address that should be used as the destination
MAC address when sending data out of the interface. MAC address when sending data out of the interface.
2. MAC address gleaning. If a dynamic routing protocol is running 2. MAC address gleaning. If a dynamic routing protocol is running
between the routers connected to the link, the MAC address of between the routers connected to the link, the MAC address of
the remote device can be taken from a data-link frame carrying the remote device can be taken from a data-link frame carrying
a packet of the corresponding routing protocol. a packet of the corresponding routing protocol.
3. ARP for reference IP address. When a point-to-point link is
configured as unnumbered, the router usually associates with
it a "reference IP address", that is used as the source IP
address in the packets originated for the unnumbered
interface. When such an address is known to a router, the
router may announce its MAC address by sending a gratuitous
ARP message. This solution will also help in the situations
where routers calculate the next-hop addresses for the routes
through point-to-point interfaces. Since the source IP address
in the received routing protocol packet is used as the next-
hop address in the route, forwarding an IP packet along such
a route will lead to an ARP request submission on the LAN
link that will be answered by the remote device.
4.5 Detection of mis-configuration 4.5 Detection of mis-configuration
With this p2p-over-lan extension, the difference between a LAN and With this p2p-over-lan extension, the difference between a LAN and
a point-to-point circuit can be made purely by configuration. It is a point-to-point circuit can be made purely by configuration. It is
important to implement the mechanisms for early detection of important to implement the mechanisms for early detection of
mis-configuration. mis-configuration.
If the circuit is configured as point-to-point type and receives If the circuit is configured as point-to-point type and receives
LAN hello packets, the router MUST discard the incoming packets; If LAN hello packets, the router MUST discard the incoming packets; If
the circuit is a LAN type and receive point-to-point hello packets, the circuit is a LAN type and receive point-to-point hello packets,
it MUST discard the incoming packets. If the system ID or the it MUST discard the incoming packets. If the system ID or the
router ID of incoming hello packet does not match the system ID or router ID of incoming hello packet does not match the system ID or
the router ID of already established adjacency over this p2p-over-lan the router ID of already established adjacency over this p2p-over-lan
circuit, it MUST discard the packet. The implementation should offer circuit, it MUST discard the packet. The implementation should offer
logging and debugging information of the above events. logging and debugging information of the above events.
5. Compatibility considerations 5. Compatibility considerations
Both routers on a LAN must support the p2p-over-lan extension Both routers on a LAN must support the p2p-over-lan extension
and both must have the LAN segment configured as a p2p-over-lan and both must have the LAN segment configured as a p2p-over-lan
circuit for successful operation. Both routers MAY also support circuit for successful operation. Both routers SHOULD support at
one of the above listed methods for mapping ip addresses on the least one of the above listed methods for mapping ip addresses on
link to MAC address, and MUST support proxy ARP on the link. If the link to MAC address. If a proprietary method of IP address to
a proprietary method of IP address to MAC address resolution is MAC address resolution is used by one router, both routers must
used by one router, both routers must be capable of using the be capable of using the same method. Otherwise, the link should
same method. Otherwise, the link should be configured as a be configured as a standard LAN link, with traditional IGP LAN
standard LAN link, with traditional IGP LAN models used. models used.
6. Scalability and deployment considerations 6. Scalability and deployment considerations
While there is advantage to use this extension on the LANs While there is advantage to use this extension on the LANs
that are connected back-to-back or only contain two routers, that are connected back-to-back or only contain two routers,
however there are tradeoffs when modeling a LAN as multiple vLANs however there are tradeoffs when modeling a LAN as multiple vLANs
and using this extension since one does sacrifice the inherent and using this extension since one does sacrifice the inherent
scalability benefits of multi-access networks. In general, scalability benefits of multi-access networks. In general,
it will increase the link-state database size, the amount of it will increase the link-state database size, the amount of
packets flooded and the route calculation overhead. Network design packets flooded and the route calculation overhead. Network design
engineers should carefully balance between the associated engineers should carefully balance between the associated
overhead. The negative scalability impact is less of a concern if overhead.
the IGP over vLANs are within a single OSPF area or ISIS level.
Deployment of the described technique brings noticeable benefits from Deployment of the described technique brings noticeable benefits from
the perspective of IP address usage, the network management and the the perspective of IP address usage, the network management and the
router configuration. Note, however, that use of the IP unnumbered router configuration. Note, however, that use of the IP unnumbered
option for point-to-point LAN links inherits the same problems as option for point-to-point LAN links inherits the same problems as
those present for serial links, i.e., not being able to ping or those present for serial links, i.e., not being able to ping or
monitor a specific interface between routers. monitor a specific interface between routers.
7. Security Issues 7. Security Considerations
This document does not introduce any new security issues to ISIS or This document does not introduce any new security issues to ISIS or
OSPF. For ARP to support unnumbered IP interface addresses, it needs OSPF. For ARP to support unnumbered IP interface addresses, it needs
to verify the p2p-over-lan circuit type described in this document to verify the p2p-over-lan circuit type described in this document
and to verify the ARP packet source interface address to match the and to verify the ARP or ND packet source interface address to match
IGP adjacency interface IP address. This is due to normal ARP sanity the IGP adjacency interface IP address.
check for common subnet can not be applied in this case.
If one router on a link thinks that a LAN should be either
broadcast or p2p-over-lan, and the other router has a different
opinion, the adjacencies will never form, as specified in
Section 4.5. There are no fallbacks at either end to resolve
the situation, except by a manual configuration change.
8. Acknowledgments 8. Acknowledgments
The authors would like to acknowledge the following individuals: The authors would like to acknowledge the following individuals:
(in last name alphabetical order) Pedro Marques, Christian Martin, (in last name alphabetical order) Pedro Marques, Christian Martin,
Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda and Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda and
Alvaro Retana. Alvaro Retana.
9. References 9. References
skipping to change at page 7, line 36 skipping to change at page 8, line 12
Use in Conjunction with the Protocol for Providing the Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 1990. Connectionless-Mode Network Service. ISO, 1990.
[ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Environments. INTERNET-RFC, Internet Engineering Task Force, Environments. INTERNET-RFC, Internet Engineering Task Force,
December 1990. December 1990.
[ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet
Engineering Task Force, 1998. Engineering Task Force, 1998.
10. Authors' Addresses [ref4] Hopps, C., "Routing IPv6 with IS-IS",
draft-ietf-isis-ipv6-05.txt, work in progress.
[ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
10. Editor Information
Naiming Shen Naiming Shen
Redback Networks Redback Networks
350 Holger Way 350 Holger Way
San Jose, CA, 95134 USA San Jose, CA, 95134 USA
naiming@redback.com naiming@redback.com
Acee Lindem
Redback Networks
102 Carric Bend Court
Cary, NC 27519 USA
acee@redback.com
Jenny Yuan
Redback Networks
350 Holger Way
San Jose, CA, 95134 USA
jenny@redback.com
Alex Zinin Alex Zinin
Alcatel Alcatel
Sunnyvale, CA, USA Sunnyvale, CA, USA
e-mail: zinin@psg.com e-mail: zinin@psg.com
Russ White Intellectual Property Considerations
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
e-mail: riw@cisco.com
Stefano Previdi The IETF takes no position regarding the validity or scope of any
Cisco Systems, Inc. intellectual property or other rights that might be claimed to
De Kleetlaan 6A pertain to the implementation or use of the technology described in
1831 Diegem - Belgium this document or the extent to which any license under such rights
email: sprevidi@cisco.com might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Notice
Copyright (C) The Internet Society (2004). 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 is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
-
 End of changes. 21 change blocks. 
92 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/