[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                   Sina Mirtorabi
Internet Draft                                          Peter Psenak
Document: draft-mirtorabi-ospf-multi-area-adj-01.txt    Cisco Systems, Inc
Expiration Date: September 2004
                                                        Acee Lindem
                                                        Anand Oswal
                                                        Redback Networks

                                                        March 2004






                         OSPF Multi-Area Adjacency
                 draft-mirtorabi-ospf-multi-area-adj-01.txt






Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    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 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 would create an intra-area path to the corresponding areas
    sharing the same link.


Mirtorabi et al.                                                [Page 1]


Internet Draft           OSPF Multi-area adjacency            March 2004



Table of Contents

             Abstract ...............................................1
    1.       Motivation..............................................2
    2.       Possible Soultions .....................................2
    3.       Proposed Soultion ......................................3
    4.       Bringing up multi-area adjacencies .....................3
    5.       Neighbor discovery......................................3
    6.       Interface data structure................................3
    7.       Interface FSM...........................................4
    8.       Neighbor data structure and neighbor FSM................4
    9.       Advertising multi-area adjacencies .....................4
    10.      Compatibility Issues....................................5
    11.      Other Solutions.........................................5
    12.      Security................................................5
    13.      Acknowledgments.........................................5
    14.      Reference...............................................5
    15.      Authors' Addresses .....................................5


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
    ABRs to create multi-area adjacencies belonging to different areas.

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.


Mirtorabi et al.                                                [Page 2]


Internet Draft           OSPF Multi-area adjacency            March 2004



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].

4. Bringing up multi-area adjacencies

   Multi-area adjacencies are configured between two routers having a
   common interface. On physical point-to-point networks, packets are
   sent to the AllSPFRouters address. For all other network types,
   packets are unicast to the remote neighbor's IP address.

5. Neighbor discovery

   On point-to-point networks, neighbor discovery is dynamic since Hello
   packets are sent to the AllSPFRouters address. For all other network
   types, one needs to configure remote neighbor IP address for the
   multi-area adjacency.

6. Change to OSPF control packet processing

   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.


Mirtorabi et al.                                                [Page 3]


Internet Draft           OSPF Multi-area adjacency            March 2004



      (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.

          For virtual link,
          the receiving router must be an area border router, and the
          Router ID specified in the packet (the source 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.

          For 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.


    [ Note if there is a match for both a VL and TA 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).

   [...]

7. Interface data structure

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

8. Interface FSM

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

9. 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 [OSPF].


Mirtorabi et al.                                                [Page 4]


Internet Draft           OSPF Multi-area adjacency            March 2004



10. Advertising multi-area adjacencies

   Multi-area adjacencis are announced as unnumbered point-to-point
   links. Once the router's secondary adjacency reaches the FULL state
   it will be added as a link type 1 to the Router LSA with:

   Link ID = remote's Router ID
   Link ID = IfIndex

   This will announce a topological path through the corresponding
   area.

11. Compatibility Issues

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

12. Other Solutions

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

13. Security

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

14. Acknowledgments

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

15. References

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

     [P2PLAN] Shen, N., et al,  "Point-to-point operation over LAN in
              link-state routing protocols",
              draft-ietf-isis-igp-p2p-over-lan-01.txt,
              Work in progress.

     [OSPFTA] Mirtorabi, S., Psenak, P., Lindem, A., "OSPF Tunnel
              Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt,
              Work in Progress.

16. Authors' Addresses

   Sina Mirtorabi                             Peter Psenak
   Cisco Systems                              Cisco Systems
   225 West Tasman drive                      Parc Pegasus, De Kleetlaan 6A
   San Jose, CA 95134                         1831 Diegem, Belgium
   e-mail: sina@cisco.com                     e-mail: ppsenak@cisco.com

   Acee Lindem                                Anand Oswal
   Redback Networks                           Redback Networks
   102 Carric Bend Court                      300 Holger Way
   Cary, NC 27519                             San Jose, CA  95134
   email: acee@redback.com                    e-mail: aoswal@redback.com


Mirtorabi et al.                                                [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/