Y.Maeno Internet Draft Y.Suemura Document: draft-maeno-ospf-optical-subnet-00.txt NEC Expires: October 2002 April 2002 OSPF Extensions in Support of Transport Plane Sub-networks 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 document specifies extensions to the OSPF routing protocol in support of carrying link state information for abstracted transport plane sub-networks and external addresses in an optical network. For this purpose, new TLV triplets for OSPF TE LSA are defined. NAME OF I-D: http://www.ietf.org/internet-drafts/draft-maeno-ospf-optical-subnet- 00.txt SUMMARY This document specifies extensions to the OSPF routing protocol in support of carrying link state information for abstracted transport plane sub-networks and external addresses in an optical network. For this purpose, new TLV triplets for OSPF TE LSA are defined. RELATED DOCUMENTS http://search.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls- extensions-05.txt http://search.ietf.org/internet-drafts/draft-many-ip-optical- framework-03.txt Maeno Informational - Expires October 2002 [page 1] OSPF Extensions in Support of an Abstracted Sub-network April 2002 http://www.ietf.org/rfc/rfc2370.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK This work fits squarely in the CCAMP box. WHY IS IT TARGETED AT THIS WG It addresses the following work item: - Develop and define a set of protocol-independent metrics and parameters for describing links and paths that can be carried in protocols. - Abstract link and path properties needed for link and path protection. Define signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signalling and measurement protocols, either separately or in combination. JUSTIFICATION The WG should consider this document as it specifically addresses one of the work items called out in the charter. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Table of Contents..................................................2 1. Introduction....................................................2 2. TE link for sub-networks........................................3 3. TLV definition..................................................5 3.1. TLV extension.................................................5 3.2. Sub-network TLV...............................................5 3.3. Sub-network ID sub-TLV........................................5 3.4. Internal address sub-TLV......................................6 3.5. External address TLV..........................................6 3.6. Client address sub-TLV........................................6 4. Security Considerations.........................................7 References.........................................................7 Author's Addresses.................................................7 1. Introduction This document specifies extensions to the OSPF routing protocol [1] in support of carrying link state information for abstracted sub- networks and external addresses in an optical network. An optical network [2] contains wide range of multiplexing hierarchies such as Maeno Informational - Expires October 2002 [page 2] OSPF Extensions in Support of an Abstracted Sub-network April 2002 SDH STM-n, technology islands such as an all-optical cross-connects (XC) and vendor clouds. Reachability between all-optical XCs is sometimes limited for optical reasons. The vendor clouds often support vendor specific automatic protection switching (APS) mechanism. These structures possessing specific transport plane functions are referred to as sub-networks. Representation of details of the specific transport plane functions is not standardized. Instead, internal structures and functions of transport plane of a sub-network is abstracted and exported to OSPF. A sub-network is often controlled by a separate routing component customized to treat the specific transport plane functions. A network management system, or a route server can be the routing component. The sub-network is abstracted by means of one or more embedded objects, which are represented as traffic-engineering (TE) links for OSPF. The routing component configures TE parameters advertised by OSPF TE LSAs for the embedded objects. This makes TE across sub- networks possible, such as diverse routing, bandwidth control, load balancing etc. For this purpose, new Type/Length/Value (TLV) triplets for TE LSA are defined. 2. TE link for sub-networks A sub-network is abstracted by one or more embedded objects, which are represented as TE links. Figure 1 illustrates an example sub- network. A sub-network consists of 6 XCs (S1 to S6) and 8 links between them (S1 - S2 etc.). The XCs within a sub-network are identified by an internal address (XC identifier). It is a 32 bit IPv4 address. The XC identifier need not be a globally unique IP address, but it must be unique only in the domain within which each XC can uniquely identify the respective peer it is communicating with. Note that this requirement is trivially satisfied, if the XC identifier is a globally unique IPv4 address. More likely is the scenario, where XC identifiers are drawn from the private IPv4 address space. The network operator assigns the XC identifier. S1, S3, S5, S6 are sub-network edge XCs. The edge XCs and neighbor XCs (X, Y, Z) are equipped with OSPF routing protocol. C denotes a client device connected to an optical network. In most cases, a routing protocol does not run across a user-network- interface (UNI) between S5 and C. The client device is identified by an external address (client device identifier). In OIF UNI1.0 specification, it is called transport network assigned (TNA) address [3]. UNI LSP endpoints are identified by TNA addresses. Each TNA address is a globally unique address assigned by transport networks to one or more data bearing links. The basis on which the network Maeno Informational - Expires October 2002 [page 3] OSPF Extensions in Support of an Abstracted Sub-network April 2002 operator assigns TNA addresses to links is a matter of operator policy. It can be an IP address, or an NSAP address. The external address of C can be assigned by S5, or can be registered to S5. X----S1----S2----S3----Y | | / | | | / | S4----S5----S6----Z | C Figure 1 Sub-network example (S1 to S6) The sub-network in figure 1 can be abstracted by a set of TE links in various ways. For example, if the maximal number of hops within the sub-network (S1 to S6) is limited to 2 for optical reasons, the sub- network is represented by the following 4 TE links. TE LSA originating from S1: S1 - (S3,S5,C) TE LSA originating from S3: S3 - (S1,S5,S6,C) TE LSA originating from S5: S5 - (S1,S3,S6,C) TE LSA originating from S6: S6 - (S3,S5,C) They provide summary link-state information. TE parameters, TE metric as an example, for S1 - S3 are the same as those for S1 - S5 etc. In this example, a client device identifier and XC identifiers are mixed into a single TE link. But, a TE link to indicate the existence of a client device, such as S5 - C, can be configured separately. Their TE parameters are advertised to X, Y, Z. Link-state database of XCs equipped with OSPF routing protocol contains LSAs for X - S1, S3 - Y, S6 - Z and the above 4 TE links. Alternatively, for example, the above 4 TE links can be substituted by the following 6 TE links. TE LSA originating from S1: S1 - (S3,S5) TE LSA originating from S3: S3 - (S1) TE LSA originating from S3: S3 - (S5,S6) TE LSA originating from S5: S5 - (S1,S3,S6) TE LSA originating from S5: S5 - (C) TE LSA originating from S6: S6 - (S3,S5) Their TE parameters are advertised to X, Y, Z. They provide less summarized and abstract link-state information. TE parameters for S3 - S1 can be different from those for S3 - S5. The edge-to-edge APS mechanism for S3 - S1 and S3 - S5 can be associated with different Link protection type. As shown above, the degree of abstraction of a sub-network can be adjusted case-by-case. As the number of XCs/client devices summarized into a single TE link, such as 4/1 for S3 - (S1,S5,S6,C), decreases, TE parameters become more accurate. To represent the above summary and abstract link-state information, extended TLVs for OSPF TE LSA are defined in the next section. Maeno Informational - Expires October 2002 [page 4] OSPF Extensions in Support of an Abstracted Sub-network April 2002 3. TLV definition 3.1. TLV extension In this section, we define extended TLVs, which can be advertised in OSPF TE LSAs, to represent a sub-network. The TE LSA, which is an opaque LSA with area flooding scope [4], has only one top-level TLV and has one or more nested TLVs for extensibility. The top-level TLV can take one of two values (1) Router address TLV or (2) Link TLV. In this document, we enhance the TLVs for the top-level TLV in support of an abstracted sub-network. Specifically, we add (3) Sub- network TLV and (4) External address TLV. This brings the list of TLVs for the top-level TLV to: TLV Type Length Name 1 4 Router address 2 variable Link TBD variable Sub-network TBD variable External address 3.2. Sub-network TLV Sub-network TLV is a TLV for the top-level TLV with type (TBD). The length is variable. The value is an unordered list of Sub-network ID TLV and Internal address TLV. The format of the value field is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3. Sub-network ID sub-TLV Sub-network ID TLV is a sub-TLV for Sub-network TLV with type (TBD). The length is 32 bits. The value is a 32 bit sub-network identifier. The format of the value field is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TBD) | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-network ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maeno Informational - Expires October 2002 [page 5] OSPF Extensions in Support of an Abstracted Sub-network April 2002 3.4. Internal address sub-TLV Internal address TLV is a sub-TLV for Sub-network TLV with type (TBD). The length is variable. For the TE link, S3 - (S1,S5,S6,C) for example, 32 bit IPv4 addresses of S1, S5, S6 are specified here. S3 is specified by Router address TLV. The format of the value field is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TBD) | 4 * No. of XC IDs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | XC ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.5. External address TLV External address TLV is a TLV for the top-level TLV with type (TBD). The length is variable. The value is an unordered list of one or more Client address sub-TLV. The format of the value field is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or more Client address sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.6. Client address sub-TLV Client address TLV is a sub-TLV for External address TLV with type (TBD). The length is dependent on Address type. For the TE link, S3 - (S1,S5,S6,C) for example, a client device identifier of C is specified here. The format of the value field is as shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (TBD) | Length | Maeno Informational - Expires October 2002 [page 6] OSPF Extensions in Support of an Abstracted Sub-network April 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address type 1: IPv4 address (32 bit) 2: IPv6 address (128 bit) 3: NSAP address (160 bit) Client ID This field includes one client device identifier. 4. Security Considerations Sub-network TLV and External address TLV proposed in this document do not raise any new security concerns. References [1] Kompella, K., et al., "OSPF Extensions in Support of Generalized MPLS," work in progress. [2] Rajagopalan, B., et al., "IP over Optical Networks: A Framework," work in progress. [3] "UNI 1.0 Signaling Specification," oif2000.125. [4] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998. Author's Addresses Yoshiharu Maeno NEC 4-1-1 Miyazaki, Miyamae-ku Phone: 8-44-856-8109 Kawasaki, 216-8555 Japan Email: y-maeno@aj.jp.nec.com Yoshihiko Suemura NEC 4-1-1 Miyazaki, Miyamae-ku Phone: 8-44-856-8109 Kawasaki, 216-8555 Japan Email: y-suemura@bp.jp.nec.com Maeno Informational - Expires October 2002 [page 7]