Network Working Group                                       S. Mirtorabi
Internet-Draft                                                 P. Psenak
Expires: January 30, 2005                                  Cisco Systems
                                                               A. Lindem
                                                        Redback Networks
                                                                A. Oswal
                                                           Cisco Systems
                                                             August 2004



                       OSPF Multi-Area Adjacency
                 draft-ietf-ospf-multi-area-adj-03.txt


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.


   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.


   This Internet-Draft will expire on January 30, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This memo documents an extension to OSPF to allow a single physical
   link to be shared by multiple areas.  This is necessary to allow the
   link to be considered an intra-area link in multiple areas.  This




Mirtorabi, et al.       Expires January 30, 2005                [Page 1]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



   would create an intra-area path to the corresponding areas sharing
   the same link.


Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2   Possible Solutions . . . . . . . . . . . . . . . . . . . .  3
     1.3   Proposed Solution  . . . . . . . . . . . . . . . . . . . .  3
     1.4   Other Solutions  . . . . . . . . . . . . . . . . . . . . .  3
   2.  Functional Specifications  . . . . . . . . . . . . . . . . . .  4
     2.1   Multi-Area Adjacency Configuration and Neighbor
           Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Multi-Area Adjacency Packet Transmission . . . . . . . . .  4
     2.3   Multi-Area Adjacency Control Packet Reception Changes  . .  4
     2.4   Interface Data Structure . . . . . . . . . . . . . . . . .  5
     2.5   Interface FSM  . . . . . . . . . . . . . . . . . . . . . .  5
     2.6   Neighbor Data Structure and Neighbor FSM . . . . . . . . .  5
     2.7   Advertising Multi-Area Adjacencies . . . . . . . . . . . .  5
   3.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.1   Normative References . . . . . . . . . . . . . . . . . . . .  9
   6.2   Informative References . . . . . . . . . . . . . . . . . . .  9
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 12
























Mirtorabi, et al.       Expires January 30, 2005                [Page 2]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



1.  Introduction


1.1  Motivation


   There could be a requirement to have a link in multiple areas in
   order to allow the link to be considered as an intra-area link in
   multiple areas and be preferred over high cost intra-area paths.  A
   simple example is to use a high speed backbone link between two Area
   Border Routers (ABRS) to create multi-area adjacencies belonging to
   different areas.


1.2  Possible Solutions


   For numbered interfaces, the OSPF specification [OSPF] allows a
   separate OSPF interface to be configured in each area using a
   secondary address.  The disadvantages of this approach are that it
   requires additional IP address configuration, doesn't apply to
   unnumbered interfaces, and advertising secondary addresses will
   result in a larger overall routing table.


   Allowing a link with a single address to simply be configured in
   multiple areas would also solve the problem.  However, this would
   result in the subnet corresponding to the interface residing in
   multiple areas which is contrary to the definition of an OSPF area as
   a collection of subnets.


   Another approach is to simply allow unnumbered links to be configured
   in multiple areas.  Section 8.2.  of the OSPF specification already
   specifies that the OSPF area ID should be used to de-multiplex
   received OSPF packets.  One limitation of this approach is that
   multi-access networks are not supported.  Although this limitation
   may be overcome for LAN media with support of "Point-to-Point
   operation over LAN in link-state routing protocols" [P2PLAN], it may
   not be acceptable to configure the link as unnumbered.


1.3  Proposed Solution


   ABRs will simply establish multiple adjacencies belonging to
   different areas.  Each multi-area adjacency is announced as a
   point-to-point unnumbered link in the configured area.  This
   point-to-point link will provide a topological path for that area.
   The first or primary adjacency using the link will operate and
   advertise the link consistent with RFC 2328 [OSPF].


1.4  Other Solutions


   The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate
   mechanism which satisfies this requirement as well as others.




Mirtorabi, et al.       Expires January 30, 2005                [Page 3]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



2.  Functional Specifications


2.1  Multi-Area Adjacency Configuration and Neighbor Discovery


   Multi-area adjacencies are configured between two routers having a
   common interface.  On physical point-to-point networks, there is no
   need to configure the neighbor's address since there can be only one
   neighbor.  For all other network types, the neighbor address of each
   multi-area adjacency must be configured or automatically discovered
   via a mechanism external to OSPF.


2.2  Multi-Area Adjacency Packet Transmission


   On physical point-to-point networks, OSPF control packets are sent to
   the AllSPFRouters address.  For all other network types, OSPF control
   packets are unicast to the remote neighbor's IP address.


2.3  Multi-Area Adjacency Control Packet Reception Changes


   Receiving protocol packets is described in section 8.2 of [OSPF] and
   is changed as follow:


   Next, the OSPF packet header is verified.  The fields specified in
   the header must match those configured for the receiving interface.
   If they do not, the packet should be discarded:
   o  The version number field must specify protocol version 2.
   o  The Area ID found in the OSPF header must be verified.  If all of
      the following cases fail, the packet should be discarded.  The
      Area ID specified in the header must either:
      1.  Match the Area ID of the receiving interface.  In this case,
          the packet has been sent over a single hop.  Therefore, the
          packet's IP source address is required to be on the same
          network as the receiving interface.  This can be verified by
          comparing the packet's IP source address to the interface's IP
          address, after masking both addresses with the interface mask.
          This comparison should not be performed on point-to-point
          networks.  On point-to-point networks, the interface addresses
          of each end of the link are assigned independently, if they
          are assigned at all.
      2.  Indicate a non-backbone area.  In this case, the packet has
          been sent over a multi-area adjacency.  If the area-id matches
          the configured area for multi-area adjacency, the packet is
          accepted and is from now on associated with the multi-area
          adjacency for that area.
      3.  Indicate the backbone.  In this case, the packet has been sent
          over a virtual link or a multi-area adjacency.
   o  For virtual links, the receiving router must be an area border
      router, and the Router ID specified in the packet (the source




Mirtorabi, et al.       Expires January 30, 2005                [Page 4]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



      router) must be the other end of a configured virtual link.  The
      receiving interface must also attach to the virtual link's
      configured transit area.  If all of these checks succeed, the
      packet is accepted and is from now on associated with the virtual
      link.
   o  For multi-area adjacencies, if the area-id matches the configured
      area for the multi-area adjacency, the packet is accepted and is
      from now on associated with the multi-area adjacency for that
      area.
   o  Note that if there is a match for both a virtual link and a
      multi-area adjacency then this is a configuration error that
      should be handled at the configuration level.
   o  Packets whose IP destination is AllDRouters should only be
      accepted if the state of the receiving interface is DR or Backup
      (see Section 9.1).
   o  [...] The remainder of section 8.2 [OSPF] is unchanged.


2.4  Interface Data Structure


   An OSPF interface data structure is built for each configured
   multi-area adjacency as specified in section 9 of [OSPF].  The
   interface type will always be point-to-point.


2.5  Interface FSM


   The interface FSM will be the same as a point-to-point link
   irrespective of the underlying physical link.


2.6  Neighbor Data Structure and Neighbor FSM


   Both the neighbor data structure and neighbor FSM are the same as for
   standard OSPF, specified in section 10 of [OSPF].


2.7  Advertising Multi-Area Adjacencies


   Multi-area adjacencies are announced as unnumbered point-to-point
   links.  Once the router's multi-area adjacency reaches the FULL state
   it will be added as a link type 1 to the Router Link State
   Advertisement (LSA) with:
      Link ID   = Remote's Router ID
      Link Data = IfIndex


   This will announce a topological path through the corresponding area.









Mirtorabi, et al.       Expires January 30, 2005                [Page 5]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



3.  Compatibility


   All mechanisms described in this document are backward-compatible
   with standard OSPF implementations [OSPF].
















































Mirtorabi, et al.       Expires January 30, 2005                [Page 6]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



4.  Security Considerations


   This document does not raise any security issues that are not already
   covered in [OSPF].
















































Mirtorabi, et al.       Expires January 30, 2005                [Page 7]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



5.  IANA Considerations


   This document does not require any IANA assignments or action.

















































Mirtorabi, et al.       Expires January 30, 2005                [Page 8]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



6.  References


6.1  Normative References


   [OSPF]  Moy, J., "OSPF Version 2", RFC 2328, April 1998.


6.2  Informative References


   [OSPFTA]  Mirtorabi, S., Psenak, P. and A. Lindem, "OSPF Tunnel
             Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt
             (work in progress).


   [P2PLAN]  Shen, N. and A. Zinin, "Point-to-point operation over LAN
             in link-state routing protocols",
             draft-ietf-isis-igp-p2p-over-lan-05.txt (work in progress).



Authors' Addresses


   Sina Mirtorabi
   Cisco Systems
   225 West Tasman Drive
   San Jose, CA  95134
   USA


   EMail: sina@cisco.com



   Peter Psenak
   Cisco Systems
   Parc Pegasus, De Kleetlaan 6A
   1831 Diegem
   Belgium


   EMail: ppsenak@cisco.com



   Acee Lindem
   Redback Networks
   102 Carric Bend Court
   Cary, NC  27519
   USA


   EMail: acee@redback.com








Mirtorabi, et al.       Expires January 30, 2005                [Page 9]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



   Anand Oswal
   Cisco Systems
   225 West Tasman Drive
   San Jose, CA  95134
   USA


   EMail: aoswal@cisco.com













































Mirtorabi, et al.       Expires January 30, 2005               [Page 10]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



Appendix A.  Acknowledgments


   The authors wish to acknowledge Pat Murphy for bringing focus to the
   requirement.


   Thanks to Mitchell Erblich's for his last call review and comments.


   The RFC text was produced using Marshall Rose's xml2rfc tool.












































Mirtorabi, et al.       Expires January 30, 2005               [Page 11]


Internet-Draft         OSPF Multi-Area Adjacency             August 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   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.



Disclaimer of Validity


   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.



Copyright Statement


   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.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Mirtorabi, et al.       Expires January 30, 2005               [Page 12]