GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6845

Internet Engineering Task Force (IETF) N. Sheth Request for Comments: 6845 Contrail Systems Updates: 2328, 5340 L. Wang Category: Standards Track J. Zhang ISSN: 2070-1721 Juniper Networks

                                                          January 2013
    OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type

Abstract

 This document describes a mechanism to model a broadcast network as a
 hybrid of broadcast and point-to-multipoint networks for purposes of
 OSPF operation.  Neighbor discovery and maintenance as well as Link
 State Advertisement (LSA) database synchronization are performed
 using the broadcast model, but the network is represented using the
 point-to-multipoint model in the router-LSAs of the routers connected
 to it.  This allows an accurate representation of the cost of
 communication between different routers on the network, while
 maintaining the network efficiency of broadcast operation.  This
 approach is relatively simple and requires minimal changes to OSPF.
 This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340).

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6845.

Sheth, et al. Standards Track [Page 1] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
 2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
 3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.1.  Interface Parameters  . . . . . . . . . . . . . . . . . . . 4
   4.2.  Neighbor Data Structure . . . . . . . . . . . . . . . . . . 4
   4.3.  Neighbor Discovery and Maintenance  . . . . . . . . . . . . 5
   4.4.  Database Synchronization  . . . . . . . . . . . . . . . . . 5
   4.5.  Generating Network-LSAs . . . . . . . . . . . . . . . . . . 5
   4.6.  Generating Router and Intra-Area-Prefix-LSAs  . . . . . . . 5
     4.6.1.  Stub Links in OSPFv2 Router-LSA . . . . . . . . . . . . 6
     4.6.2.  OSPFv3 Intra-Area-Prefix-LSA  . . . . . . . . . . . . . 6
   4.7.  Next-Hop Calculation  . . . . . . . . . . . . . . . . . . . 6
   4.8.  Graceful Restart  . . . . . . . . . . . . . . . . . . . . . 6
 5.  Compatibility Considerations  . . . . . . . . . . . . . . . . . 6
 6.  Scalability and Deployment Considerations . . . . . . . . . . . 7
 7.  Management Considerations . . . . . . . . . . . . . . . . . . . 7
 8.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
 9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
 10. Normative References  . . . . . . . . . . . . . . . . . . . . . 8

Sheth, et al. Standards Track [Page 2] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

1. Introduction

 OSPF [RFC2328] operation on broadcast interfaces takes advantage of
 the broadcast capabilities of the underlying medium for doing
 neighbor discovery and maintenance.  Further, it uses a Designated
 Router (DR) and Backup Designated Router (BDR) to keep the Link State
 Advertisement (LSA) databases of the routers on the network
 synchronized in an efficient manner.  However, it has the limitation
 that a router cannot advertise different costs to each of the
 neighboring routers on the network in its router-LSA.
 Consider a radio network that supports true broadcast, yet the
 metrics between different pairs of terminals could be different for
 various reasons (e.g., different signal strength due to placement).
 When running OSPF over the radio network, for a router to advertise
 different costs to different neighbors, the interface must be treated
 as point-to-multipoint (P2MP), even though the network has true
 broadcast capability.
 Operation on point-to-multipoint interfaces could require explicit
 configuration of the identity of neighboring routers.  It also
 requires the router to send separate Hellos to each neighbor on the
 network.  Further, it mandates establishment of adjacencies to all
 configured or discovered neighbors on the network.  However, it gives
 the routers the flexibility to advertise different costs to each of
 the neighboring routers in their router-LSAs.
 This document proposes a new interface type that can be used on
 networks that have broadcast capability.  In this mode, neighbor
 discovery and maintenance, as well as database synchronization are
 performed using existing procedures for broadcast mode.  The network
 is modeled as a collection of point-to-point links in the router-LSA,
 just as it would be in point-to-multipoint mode.  This new interface
 type is referred to as hybrid-broadcast-and-P2MP in the rest of this
 document.

2. Requirements Language

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

3. Motivation

 There are some networks that are broadcast capable but have a
 potentially different cost associated with communication between any
 given pair of nodes.  The cost could be based on the underlying

Sheth, et al. Standards Track [Page 3] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

 topology as well as various link quality metrics such as bandwidth,
 delay, and jitter, among others.
 It is not accurate to treat such networks as OSPF broadcast networks
 since that does not allow a router to advertise a different cost to
 each of the other routers.  Using OSPF point-to-multipoint mode would
 satisfy the requirement to correctly describe the cost to reach each
 router.  However, it would be inefficient in the sense that it would
 require forming O(N^2) adjacencies when there are N routers on the
 network.
 It is advantageous to use the hybrid-broadcast-and-P2MP type for such
 networks.  This combines the flexibility of point-to-multipoint type
 with the advantages and efficiencies of broadcast interface type.

4. Operation

 OSPF routers supporting the capabilities described herein should have
 support for an additional hybrid-broadcast-and-P2MP type for the Type
 data item described in Section 9 of [RFC2328].
 The following sub-sections describe salient aspects of OSPF operation
 on routers configured with a hybrid-broadcast-and-P2MP interface.

4.1. Interface Parameters

 The "Router Priority" interface parameter as specified in OSPFv2
 [RFC2328] and OSPFv3 [RFC5340] applies to a hybrid-broadcast-and-P2MP
 interface.
 The "LinkLSASuppression" interface parameter as specified in OSPFv3
 [RFC5340] applies to a hybrid-broadcast-and-P2MP interface.  The
 default value is "disabled".  It may be set to "enabled" via
 configuration.

4.2. Neighbor Data Structure

 An additional field called the Neighbor Output Cost is added to the
 neighbor data structure.  This is the cost of sending a data packet
 to the neighbor, expressed in the link state metric.  The default
 value of this field is the Interface output cost.  It may be set to a
 different value using mechanisms that are outside the scope of this
 document, like static per-neighbor configuration, or any dynamic
 discovery mechanism that is supported by the underlying network.

Sheth, et al. Standards Track [Page 4] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

4.3. Neighbor Discovery and Maintenance

 Routers send and receive Hellos so as to perform neighbor discovery
 and maintenance on the interface using the procedures specified for
 broadcast interfaces in [RFC2328] and [RFC5340].

4.4. Database Synchronization

 Routers elect a DR and BDR for the interface and use them for initial
 and ongoing database synchronization using the procedures specified
 for broadcast interfaces in [RFC2328] and [RFC5340].

4.5. Generating Network-LSAs

 Since a hybrid-broadcast-and-P2MP interface is described in router-
 LSAs using a collection of point-to-point links, the DR MUST NOT
 generate a network-LSA for the interface.

4.6. Generating Router and Intra-Area-Prefix-LSAs

 Routers describe the interface in their router-LSA as specified for a
 point-to-multipoint interface in Section 12.4.1.4 of [RFC2328] and
 Section 4.4.3.2 of [RFC5340], with the following modifications for
 Type 1 links:
 o  If a router is not the DR and does not have a full adjacency to
    the DR, it MUST NOT add any Type 1 links.
 o  If a router is not the DR and has a full adjacency to the DR, and
    both the DR and this router agree on the DR role, it MUST add a
    Type 1 link corresponding to each neighbor that is in state 2-Way
    or higher and to which the DR's router-LSA includes a link.
 o  The cost for a Type 1 link corresponding to a neighbor SHOULD be
    set to the value of the Neighbor Output Cost field as defined in
    Section 4.2.

4.6.1. Stub Links in OSPFv2 Router-LSA

 Routers MUST add a Type 3 link for their own IP address to the
 router-LSA as described in Section 12.4.1.4 of [RFC2328].  Further,
 they MUST also add a Type 3 link with the Link ID set to the IP
 subnet address, Link Data set to the IP subnet mask, and cost equal
 to the configured output cost of the interface.

Sheth, et al. Standards Track [Page 5] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

4.6.2. OSPFv3 Intra-Area-Prefix-LSA

 Routers MUST add globally scoped IPv6 addresses on the interface to
 the intra-area-prefix-LSA as described for point-to-multipoint
 interfaces in Section 4.4.3.9 of [RFC5340].  In addition, they MUST
 also add all globally scoped IPv6 prefixes on the interface to the
 LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix
 fields.  The Metric field for each of these prefixes is set to the
 configured output cost of the interface.
 The DR MUST NOT generate an intra-area-prefix-LSA for the transit
 network for this interface since it does not generate a network-LSA
 for the interface.  Note that the global prefixes associated with the
 interface are advertised in the intra-area-prefix-LSA for the router
 as described above.

4.7. Next-Hop Calculation

 Next-hops to destinations that are directly connected to a router via
 the interface are calculated as specified for a point-to-multipoint
 interface in Section 16.1.1 of [RFC2328].

4.8. Graceful Restart

 The following modifications to the procedures defined in Section 2.2,
 item 1, of [RFC3623] are required in order to ensure that the router
 correctly exits graceful restart.
 o  If a router is the DR on the interface, the pre-restart network-
    LSA for the interface MUST NOT be used to determine the previous
    set of adjacencies.
 o  If a router is in state DROther on the interface, an adjacency to
    a non-DR or non-BDR neighbor is considered as reestablished when
    the neighbor state reaches 2-Way.

5. Compatibility Considerations

 All routers on the network must support the hybrid-broadcast-and-P2MP
 interface type for successful operation.  Otherwise, the interface
 should be configured as a standard broadcast interface.
 If some routers on the network treat the interface as broadcast and
 others as hybrid-broadcast-and-P2MP, neighbors and adjacencies will
 still get formed as for a broadcast interface.  However, due to the
 differences in how router and network-LSAs are built for these two

Sheth, et al. Standards Track [Page 6] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

 interface types, there will be no traffic traversing certain pairs of
 routers.  Note that this will not cause any persistent loops or
 black-holing of traffic.
 To detect and flag possible mismatched configurations, an
 implementation of this specification SHOULD log a message if a
 network-LSA is received for a locally configured hybrid interface.

6. Scalability and Deployment Considerations

 Treating a broadcast interface as hybrid-broadcast-and-P2MP results
 in O(N^2) links to represent the network instead of O(N), when there
 are N routers on the network.  This will increase memory usage and
 have a negative impact on route calculation performance on all the
 routers in the area.  Network designers should carefully weigh the
 benefits of using the new interface type against the disadvantages
 mentioned here.

7. Management Considerations

 The following MIB variable/value should be added to the appropriate
 OSPFv2 and OSPFv3 MIBs ([RFC4750], [RFC5643]).
 o  For ospfIfType/ospfv3IfType, a new value broadcast-P2MP-hybrid (X)
    for the hybrid interface type (X to be defined when the revised
    MIB documents are approved).
 o  For ospfNbrEntry/ospfv3NbrEntry, an ospfNbrMetricValue/
    ospfv3NbrMetricValue attribute for per-neighbor metrics.  In case
    of non-hybrid interfaces, the value is the same as the interface
    metric.
 This section is not normative.

8. Security Considerations

 This document raises no new security issues for OSPF.  Security
 considerations for the base OSPF protocol are covered in [RFC2328],
 [RFC5340], and [RFC6506].

9. Acknowledgements

 The authors would like to thank Acee Lindem and Richard Ogier for
 their comments and suggestions.

Sheth, et al. Standards Track [Page 7] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

10. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
 [RFC3623]  Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
            Restart", RFC 3623, November 2003.
 [RFC4750]  Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F.
            Baker, "OSPF Version 2 Management Information Base",
            RFC 4750, December 2006.
 [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
            for IPv6", RFC 5340, July 2008.
 [RFC5643]  Joyal, D. and V. Manral, "Management Information Base for
            OSPFv3", RFC 5643, August 2009.
 [RFC6506]  Bhatia, M., Manral, V., and A. Lindem, "Supporting
            Authentication Trailer for OSPFv3", RFC 6506,
            February 2012.

Sheth, et al. Standards Track [Page 8] RFC 6845 OSPF Hybrid Broadcast and P2MP Intf Type January 2013

Authors' Addresses

 Nischal Sheth
 Contrail Systems
 2350 Mission College Blvd, #1140
 Santa Clara, CA  95054
 US
 EMail: nsheth@contrailsystems.com
 Lili Wang
 Juniper Networks
 10 Technology Park Dr.
 Westford, MA  01886
 US
 EMail: liliw@juniper.net
 Jeffrey Zhang
 Juniper Networks
 10 Technology Park Dr.
 Westford, MA  01886
 US
 EMail: zzhang@juniper.net

Sheth, et al. Standards Track [Page 9]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6845.txt · Last modified: 2013/01/15 00:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki