[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                 Acee Lindem
Internet Draft                                        Anand Oswal
Expiration Date: January 2004                         Redback Networks
                                                      July 2002




                             OSPF Multi-Area Links
                      draft-lindem-ospf-multi-area-links-00.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 multi-areas. This is necessary to allow the
    link to be considered as an intra-area link in multiple areas and
    be preferred over high cost intra-area paths. Unlike existing
    mechanisms, this extension does not require additional layer 2
    encapsulations or secondary addresses.



Lindem, Oswal                                                  [Page 1]


Internet Draft         OSPF Multi-Area Links                  July 2003


Table of Contents

             Abstract ............................................... 1
    1        Motivation.............................................. 2
    2        Proposed Soultion ...................................... 3
    3        Backward compatibility ................................. 4
    4        Other Solutions ........................................ 4
    5        Security Considerations ................................ 4
    6        References ............................................. 4
    7        Acknowledgments ........................................ 4
    8        Authors' Addresses ..................................... 4

1.  Motivation

    In OSPF routing domains, it is common for the OSPF backbone links
    to be higher bandwidth than the non-backbone links. It is also
    common for non-backbone areas to be connected via multiple ABRs
    which are also connected by backbone links. For example:

         R5
         |       Area 0
         |
         R1 ------- Area 0 --------- R2
         |           Oc48            |
        Area 1                    Area 1
         Oc3        Area 1          Oc3
         |                           |
        R3----------Area 1 --------- R4
                     DS1             |
                                     N1


    The backbone Oc48 link connecting R1 and R2 in area 0 is clearly
    the highest bandwidth and lower cost path between R1 and N4.
    However, the path R1->R3->R4->N1 will be preferred since it is
    an Area 1 intra-area path. In this situation, one would like the
    higher bandwidth link between R1 and R2 to be treated as a link
    in both Area 1 and Area 0.


Lindem, Oswal                                                  [Page 2]


Internet Draft         OSPF Multi-Area Links                  July 2003

2.  Proposed Solution

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

    The above problems can be avoided by simply allowing unnumbered
    links to be configured in multiple areas. This will allow a
    higher bandwidth link to be used in multiple areas without using
    additonal layer 2 encapsulations or secondary addresses. 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 is that multi-access networks are not supported.
    However, this limitation may be overcome for LAN media with
    support of "Point-to-Point operation over LAN in link-state
    routing protocols" [P2PLAN].


Lindem, Oswal                                                  [Page 3]


Internet Draft         OSPF Multi-Area Links                  July 2003



3.  Backward compatibility

    This proposal does not introduce any backward compatibility
    issues with to other routers in the OSPF routing domain or area.
    For interoperability, both endpoints of the link must support
    allow configuration in multiple areas.

4.  Other Solutions

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

5. Security Considerations

    The described technique does not introduce any new security issues
    into OSPF protocol.

6. 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., "OSPF Tunnel Adjacency",
              draft-mirtorabi-ospf-tunnel-adjacency-00.txt,
              Work in Progress.



7. Acknowledgments

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

8. Authors' Addresses

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


Lindem, Oswal                                                  [Page 4]