One document matched: draft-acee-ospf-multi-instance-02.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<rfc category="std" ipr="full3978" docName="draft-acee-ospf-multi-instance-02.txt">

<front>
<title abbrev="OSPF Multi-Instance Extensions">
   OSPF Multi-Instance Extensions</title>
  <author initials='A.' surname="Lindem" fullname='Acee Lindem'>
    <organization>Redback Networks</organization>
    <address>
      <postal>
        <street>102 Carric Bend Court</street>
        <city>Cary</city> <region>NC</region> 
        <country>USA</country>
        <code>27519</code> 
       </postal>
       <email>acee@redback.com</email>
    </address>
    </author>

  <author initials='A.' surname="Roy" fullname='Abhay Roy'>
    <organization>Cisco Systems</organization>
    <address>
      <postal>
        <street>225 West Tasman Drive</street>
        <city>San Jose</city> <region>CA</region> 
        <country>USA</country>
        <code>95134</code> 
      </postal> 
      <email>akr@cisco.com</email>
    </address>
    </author>

  <author initials='S' surname="Mirtorabi" fullname='Sina Mirtorabi'>
    <organization>Nuova Systems</organization>
    <address>
      <postal> 
        <street>3 West Plumeria Drive</street>
        <city>San Jose</city> <region>CA</region> 
        <country>USA</country>
        <code>95134</code> 
      </postal> 
      <email>sina@nuovasystems.com</email>
    </address>
    </author>
  <date month="September" year="2008"/>
  <abstract><t>OSPFv3 includes a mechanism for supporting multiple 
   instances on the same link.
   OSPFv2 could benefit from such a mechanism in order to support 
   multiple routing domains on the same subnet. The OSPFv2 instance
   ID is reserved for support of separate OSPFv2 protocol 
   instances. This is different from OSPFv3
   where it could be used for other purposes such as putting the same 
   link in multiple areas. OSPFv2 supports this capability using a separate
   subnet or the OSPF multi-area adjacency capability.
   </t>
  </abstract>
</front>

<middle>
<section title="Introduction">
  <t>OSPFv3 <xref target="OSPFV3"/> includes a mechanism for supporting multiple instances
   on the same link. OSPFv2 <xref target="OSPFV2"/> could benefit from 
   such a mechanism in order to support multiple routing domains on the same subnet.
   The OSPFv2 instance ID is reserved for support of separate OSPFv2 protocol instances.
   This is different from OSPFv3 where it could be used for other purposes such as
   putting the same link in multiple areas. OSPFv2 supports this capability using a separate
   subnet or the OSPF multi-area adjacency capability <xref target="MULTI-AREA"/>.
   </t>
  <section title="Requirements notation">
   <t>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 <xref target="RFC-KEYWORDS"/>.</t>
   </section>
</section>

<section title="OSPFv2 Instance Packet Encoding">
   <t>OSPFv2 currently doesn't offer a mechanism to differentiate packets for
      different instances sent and received on the same interface. In support
      of this capability, this document introduces a modified packet header format when
      the Authentication Type field is split into an instance ID and type.</t>
   <t><figure title="The OSPFv2 Packet Header">
     <artwork>
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Version #   |     Type      |         Packet length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Router ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Area ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Checksum             |  Instance ID  |  AuType       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
   </figure>

   <vspace blankLines="1" /><list style="hanging">  
   <t hangText="Version #"><vspace blankLines="0" />
       The OSPFv2 version number - 2</t>

   <t hangText="Type"><vspace blankLines="0" />
       The OSPFv2 packet type as specified <xref target="OSPFV2"/>.</t>

   <t hangText="Packet length"><vspace blankLines="0" />
       The length of the OSPF protocol packet in bytes.  This length
       includes the standard OSPF header.</t>

   <t hangText="Router ID"><vspace blankLines="0" />
       The Router ID of the packet's source.</t>

   <t hangText="Area ID"><vspace blankLines="0" />
       A 32-bit number identifying the area corresponding the packet as 
       specified in <xref target="OSPFV2"/>.</t>

    <t hangText="Checksum"><vspace blankLines="0" />
       OSPFv2 standard checksum calculation as specified in 
       specified in <xref target="OSPFV2"/>.</t>

    <t hangText="Instance ID"><vspace blankLines="0" />
       Enables multiple instances of OSPF to be run over a single link.
       Each protocol instance would be assigned a separate Instance ID;
       the Instance ID has local subnet significance only. Received
       packets with an Instance ID not equal to one of the configured 
       OSPF Instance IDs on the receiving interface MUST be discarded.</t>

   <t hangText="AuType"><vspace blankLines="0" />
       OSPFv2 authentication type as specified in 
       specified in <xref target="OSPFV2"/>.</t>

   <t hangText="Authentication"><vspace blankLines="0" />
      A 64-bit field for Authentication type dependent authentication data.</t>
   </list></t>
</section> 

<section title="OSPF Interface Instance ID">                        
<t>OSPF <xref target="OSPFV2"/> describes 
the conceptual interface data structure in section 9. The OSPF Interface ID will be added to this 
structure. The Interface Instance ID will default to 0. Its setting to a non-zero value may be
accomplished through configuration or implied by some usage beyond the scope of this document.</t>
<section anchor="packet-processing" title="Sending and Receiving OSPF packets">                        
<t>When sending OSPF packets, if the interface instance ID has a non-zero value, it will
be set in the OSPF packet header. When receiving OSPF packets, 
the OSPFv2 Header Instance ID will be used to aid in demultiplexing the packet and routing it to
the correct OSPFv2 instance. Received packets with an Instance ID not equal to one of the 
configured OSPF Instance IDs on the receiving interface MUST be discarded.</t>
</section>
</section>
<section title="State Sharing Optimizations between OSPF instances">
<t>This is beyond the scope of this draft and is an area for further study.</t>
</section>
<section title="Backward Compatibility and Deployment Considerations">
<t>When there are OSPF routers that support this capability on the same broadcast capable link as
those that do not, packets with non-zero Instance IDs will be received by those legacy 
routers. Since the authentication type will be unknown to them they will not process the packet.
This is exactly what is desired.</t>
<t>Previously, a concern was that some implementations will log every single authentication 
type mismatch. However, discussions with implementers have led us to the conclusion that 
this is not as current a problem as we'd first thought and it will be even less of a problem by
the time the mechanism in this draft is standardized, implemented, and deployed. Hence, the
controversial mechanisms to avoid legacy routers receiving multicast OSPF packets with a 
non-zero instance ID have been removed.</t> 
</section>
<section title="Security Considerations">                        
<t>The enhancement described herein doesn't add any additional security
   considerations to OSPFv2. Security considerations for OSPFv2 are described
   in <xref target="OSPFV2"/>.</t> 
  <t>Given that only three OSPFv2 authentication types have been
   standardized, it seems reasonable to reduce the OSPF packet header field to 8 bits.</t> 
</section>
<section title="IANA Considerations">
   <t>A new registry will be added for OSPF Instance IDs. The allocation is TBD.</t>
   <t>Dependent on the approach, two new multicast addresses from the IPv4 Multicast 
      Addresses registry would need to be allocated.</t>
   <t>Dependent on the approach, a new protocol ID may need to be allocated from
      the Protocol Numbers registry.</t>
 </section>

</middle>

<back>
<references title="Normative References">
<reference anchor="RFC-KEYWORDS">
<front>
<title>Key words for use in RFC's to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>

<reference anchor="OSPFV2">
<front>
<title>OSPF Version 2</title>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Ascend Communications, Inc</organization>
</author>
<date month="April" year="1998" />
</front>
<seriesInfo name="RFC" value="2328" />
</reference>

<reference anchor="OSPFV3">
<front>
<title>OSPF for IPv6</title>
<author initials="R." surname="Coltun" fullname="Rob Coltun">
<organization>Acoustra Productionss</organization>
</author>
<author initials="D." surname="Ferguson" fullname="Dennis Ferguson">
<organization>Juniper Network, Inc</organization>
</author>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Sycamore Systems, Inc</organization>
</author>
<author initials="A." surname="Lindem" fullname="John Moy">
<organization>Redback Networks</organization>
</author>
<date month="July" year="2008" />
</front>
<seriesInfo name="RFC" value="5340" />
</reference>

<reference anchor="MULTI-AREA">
<front>
<title>OSPF Multi-Area Adjacency</title>
<author initials="S." surname="Mirtorabi" fullname="Sina Mirtorabi">
<organization>Force10 Networks</organization>
</author>
<author initials="P." surname="Psenak" fullname="Peter Psenak">
<organization>Cisco Systems</organization>
</author>
<author initials="A." surname="Lindem" fullname="Acee Lindem">
<organization>Redback Networks</organization>
</author>
<author initials="A." surname="Oswal" fullname="Anand Oswal">
<organization>Redback Networks</organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5185" />
</reference>
</references>

<section title="Acknowledgments">
  <t>The RFC text was produced using Marshall Rose's xml2rfc tool.</t>
  <t>Thanks to Paul Wells for commenting on the backward compatibility issues.</t>
</section>
</back>

</rfc>