idnits 2.17.1 draft-takeda-l1vpn-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1222. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1228), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2005) is 6887 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tomonori Takeda (Editor) 3 Internet Draft NTT 4 Proposed Status: Informational 5 Expires: December 2005 June 2005 7 Framework and Requirements for Layer 1 Virtual Private Networks 8 draft-takeda-l1vpn-framework-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be 32 accessed at http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document provides a framework and service level requirements 41 for Layer 1 Virtual Private Networks (L1VPNs). This framework is 42 intended to aid in developing and standardizing protocols and 43 mechanisms to support interoperable L1VPNs. 45 The document examines motivations for L1VPNs, high level (service 46 level) requirements, and outlines some of the architectural models 47 that might be used to build L1VPNs. 49 Contents 50 1. Contributors ............................................... 2 51 2. Terminology ................................................ 3 52 3. Introduction ............................................... 4 53 3.1 Overview ................................................... 5 54 3.1.1 Network Topology ........................................... 5 55 3.1.2 Introducing Layer 1 VPNs ................................... 5 56 3.1.3 Current Technologies for Dynamic Layer 1 Provisioning ...... 5 57 3.2 Relationship with ITU-T .................................... 6 58 4. Motivations ................................................ 7 59 4.1 Basic Layer 1 Services ..................................... 7 60 4.1.1 L1VPN for Dynamic Layer 1 Provisioning ..................... 8 61 4.2 Merits of L1VPN ............................................ 8 62 4.2.1 Customer Merits ............................................ 8 63 4.2.2 Provider Merits ............................................ 9 64 4.3 L1VPN Deployment Scenarios ................................. 9 65 4.3.1 Multi-Service Backbone ..................................... 9 66 4.3.2 Carrier's Carrier .......................................... 10 67 4.3.3 Layer 1 Resource Trading .................................. 10 68 4.3.4 Inter-SP L1VPN ............................................. 11 69 4.3.5 Other Scenarios ............................................ 11 70 5. Reference Models ........................................... 11 71 5.1 Management Systems ......................................... 12 72 6. Generic Service Description ................................ 13 73 6.1 CE Construct ............................................... 13 74 6.2 Generic Service Features ................................... 13 75 7. Service Models ............................................. 13 76 7.1 Management-based Service Model ............................. 14 77 7.2 Signaling-based Service Model (Basic Mode) ................. 14 78 7.2.1 Overlay Service Model ...................................... 15 79 7.3 Signaling and Routing Service Model (Enhanced Mode) ........ 15 80 7.3.1 Overlay Extension Service Model ............................ 16 81 7.3.2 Virtual Node Service Model ................................. 16 82 7.3.3 Virtual Link Service Model ................................. 17 83 7.3.4 Per-VPN Peer Service Model ................................. 18 84 8. Service Models and Service Requirements .................... 18 85 8.1 Detailed Service Level Requirements ........................ 20 86 9. Security Considerations .................................... 21 87 9.1 Types of Information ....................................... 21 88 9.2 Security Features .......................................... 22 89 9.3 Scenarios .................................................. 22 90 10. Acknowledgements ........................................... 23 91 11. Normative References ....................................... 23 92 12. Informative References ..................................... 23 93 13. Authors' Addresses ......................................... 24 94 14. Intellectual Property Consideration ........................ 25 95 15. Full Copyright Statement ................................... 26 97 1. Contributors 98 This document is based heavily on the work of ITU-T Study Group 13 99 Question 11. SG13/Q11 has been investigating the service requirements 100 and architecture for Layer 1 VPNs for some time, and this document 101 is a summary and development of the conclusions they have reached. As 102 such, ITU-T SG13 should be seen as a major contributor to this 103 document. 105 The details of this document are the result of contributions from 106 several authors who are listed here in alphabetic order. Contact 107 details for these authors can be found in a separate section near 108 the end of this document. 110 Raymond Aubin (Nortel) 111 Marco Carugi (Nortel) 112 Ichiro Inoue (NTT) 113 Hamid Ould-Brahim (Nortel) 114 Tomonori Takeda (NTT) 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 The reader is assumed to be familiar with the terminology in 123 [RFC3031], [RFC3209], [RFC3471], [RFC3473], [GMPLS-ROUTING] and 124 [RFC4026]. 126 In addition, following new terms are used within this document. 128 - Virtual link: A provider network TE link advertised to customers in 129 routing information for purposes which include path computation. A 130 data link may or may not exist between the two end points of a 131 virtual link. 133 - Virtual node: A provider network logical node advertised to 134 customers in routing information. A virtual node may represent a 135 single physical node, or multiple physical nodes and links. 137 - VPN end point: A CE's data plane interface, which is connected to a 138 PE device, and which is part of the VPN membership. Note that a 139 data plane interface is associated with a TE link end point. For 140 example, if a CE router's interface is a channelized interface 141 (defined in SONET/SDH), a channel in the channelized interface can 142 be a data plane interface. 144 - VPN connection (or connection in the L1VPN context): A connection 145 between a pair of VPN end points. Note that in some scenarios, a 146 connection may be established between a pair of Cs (customer 147 devices), using this CE-CE VPN connection as a segment or 148 forwarding adjacency. 150 Note that following terms are aligned with PPVPN terminology 151 [RFC4026], and in this document, have a meaning in the context of 152 L1VPNs, unless otherwise specified. 154 - CE (Customer Edge) device: A CE device is a customer device that 155 receives L1VPN service from the provider. A CE device is connected 156 to at least one PE device. A CE device can be a variety of devices, 157 for example, TDM cross connect, router, and L2 switch. A CE device 158 does not have to have the capability to switch at layer 1, but it 159 must be capable of receiving a layer 1 signal and either switching 160 it or terminating it with adaptation. A CE device may also be 161 attached to one or more C devices on the customer site. 163 - PE (Provider Edge) device: A PE device is a provider device that 164 provides L1VPN service to the customer. A PE device is connected to 165 at least one CE device. A layer 1 PE device is a Time Division 166 Multiplex (TDM) switch, an Optical Cross-Connect (OXC), a Fiber 167 Switch (FXC), or a PE device may be an EPL (Ethernet Private Line) 168 type of device, that maps Ethernet frames onto layer 1 connections. 170 - P (Provider) device: A P device is a provider device, which is 171 connected only to other provider devices (P or PE devices). A layer 172 1 P is a TDM switch, OXC, or FXC. 174 - Customer: A Customer has authority over a set of CE devices within 175 the same VPN (e.g., the owner of CE devices). Note that a customer 176 may outsource the management of CE devices to other organizations, 177 including to the provider itself. 179 - Provider: A Provider has authority over the management of the 180 provider network. 182 3. Introduction 184 The document examines motivations for Layer 1 Virtual Private 185 Networks (L1VPNs), provides high level (service level) requirements, 186 and outlines some of the architectural models that might be used to 187 build L1VPNs. 189 The objective of the document is mainly to present the requirements 190 and architecture work in this field that has been undertaken within 191 the ITU-T. 193 L1VPNs provide services over layer 1 networks. This document provides 194 a framework for L1VPNs and the realization of the framework by those 195 networks being controlled by GMPLS protocols. 197 3.1 Overview 199 3.1.1 Network Topology 201 The layer 1 network, made of Optical Cross-Connects (OXCs), Time 202 Division Multiplex (TDM) capable switches, or Fiber Switches (FXCs) 203 may be seen as consisting of provider edge (PE) devices that give 204 access from outside of the network, and provider (P) devices that 205 operate only within the core of the network. Similarly, outside the 206 layer 1 network is the customer network consisting of customer (C) 207 devices with access to the layer 1 network made through customer edge 208 (CE) devices. 210 A CE and PE are connected by one or more links. A CE may also be 211 connected to more than one PE, and a PE may have more than one CE 212 connected to it. 214 3.1.2 Introducing Layer 1 VPNs 216 The concept of a provider provisioned VPN (PPVPN) has been 217 established through many previous documents such as [L2VPN-FRAME] and 218 [L3VPN-FRAME]. Terminology for PPVPNs is set out in [RFC4026] with 219 special reference to layer 2 and layer 3 VPNs. 221 The realization of Layer 1 VPNs (L1VPNs) can be based on extensions 222 of the concepts of the PPVPN to the layer 1 network. It must be 223 understood that meeting the requirements set out in this document may 224 necessitate modifications to the existing mechanisms both for the 225 control plane within the layer 1 network and for service provisioning 226 at the edge of the network (CE and PE devices). It is at the 227 interface between CE and PE devices that the L1VPN service is 228 provided. 230 Note that one of the fundamental differences between L1VPNs and L2/L3 231 VPNs is that in L1VPNs data plane connectivity does not guarantee 232 control plane connectivity (and vice versa). CE-PE control plane 233 connectivity is essential, and CE-CE data plane connectivity is 234 maintained by signaling mechanisms based on this control plane 235 connectivity. The provision of CE-CE control plane connectivity over 236 the provider network is also a unique aspect of the L1VPN services, 237 by which control packets can be exchanged between CEs over the 238 control plane of the provider network. 240 3.1.3 Current Technologies for Dynamic Layer 1 Provisioning 242 Pre-existing efforts at standardization have focused on the provision 243 of dynamic connections within the layer 1 network (signaling and 244 routing), and the interfaces for requesting services between the CE 245 and PE, or between PEs at network boundaries (UNI and E-NNI 246 respectively). 248 Current UNIs include features to facilitate requests for end-to-end 249 (that is, CE to CE) services that include the specification 250 of constraints such as explicit paths, bandwidth requirements, 251 protection needs, and (of course) destinations. 253 Current E-NNIs include features to exchange routing information, as 254 well as to facilitate requests for end-to-end services. 256 The UNIs and E-NNIs, however, do not provide a sufficiently high 257 level of service to support VPNs without some additions. For example, 258 there is no way to distinguish between control messages received over 259 a shared control link (i.e., a control link shared by multiple VPNs) 260 at a UNI/E-NNI, and these messages must be disambiguated to determine 261 the L1VPN to which they apply. 263 Furthermore, there is no clear defined way to restrict connectivity 264 among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing 265 information exchange, but there is no clear defined way to allow 266 limited routing information exchange (i.e., a specific set of routing 267 information is distributed to a specific set of CEs). 269 In order that L1VPNs can be supported in a fully functional manner, 270 these deficiencies and other requirements set out later in this 271 document must be addressed. 273 3.2 Relationship with ITU-T 275 This document is based on the work of the ITU-T Study Group 13 276 Question 11. This group has been researching and specifying both the 277 requirements and the architecture of L1VPNs for some time. In this 278 context, this document is a representation of the findings of the 279 ITU-T, and a presentation of those findings in terms and format that 280 are familiar to the IETF. 282 In particular, this document is limited to the areas of concern of 283 the IETF. That is, it is limited to layer 1 networks that utilize 284 IP as the underlying support for their control plane. 286 This document presents the requirements and architectures developed 287 within the ITU-T for better understanding within the IETF and to 288 further cooperation between the two bodies. 290 Some work related to the L1VPN solution space has already been done 291 within the IETF. This document sets a framework of requirements and 292 architecture into which solutions can fit. 294 4. Motivations 296 In this discussion many merits and motivations may be taken for 297 granted. 299 The general benefits and desirability of VPNs has been described 300 many times and in many places. This document does not dwell on the 301 merits of VPNs as such, but focuses entirely on the applicability 302 of the VPN concept to layer 1 networks. 304 Similarly, the utility and value of a control plane for the 305 configuration, management and operation of a layer 1 network is 306 well-rehearsed. 308 4.1 Basic Layer 1 Services 310 Basic layer 1 services may be characterized in terms that include: 312 - Connectivity: Between a pair of CEs. 313 - Capacity: For example, the bit rate for a TDM service or the 314 capacity of a lambda. 315 - Transparency: For example, for an SDH network, overhead 316 transparency. 317 - Availability: The percentage of time that the offered service 318 meets the agreed criteria. To achieve the required level of 319 availability for the customer connections the service provider's 320 network may use restoration or protected resources. 321 - Performance: The quality of the service delivered to customers, 322 e.g., the number of error-seconds per month. 324 The layer 1 services may be categorized based on the combination of 325 connectivity features (data plane) and service control capability 326 features (control plane) available to the customer. A CE is 327 associated with the service interface between a customer site and the 328 provider network, and the categorization can be seen in the context 329 of this service interface as follows. 331 1. A single connection between a pair of CEs. 333 - Static Service 334 The classic private line service achieved through a permanent 335 connection. 337 - Dynamic Service 338 Either a switched connection service, or a customer-controlled 339 soft permanent connection service 341 2. Multiple connections among a set of CEs. 343 - Static Service 344 A private network service consisting of a mesh of permanent 345 connections. 347 - Dynamic Service 348 A dynamic private network service consisting of any combination 349 of switched connection services and customer-controlled soft 350 permanent connection services. 352 For both service types, connections are point-to-point, and can be 353 permanent, soft-permanent, or switched. For a static service, the 354 management plane of the provider network is responsible for the 355 management of both the network infrastructure and the end-user 356 connections. For dynamic services, the management plane of the 357 provider network is only responsible for the configuration of the 358 infrastructure; end-user connections are established dynamically via 359 the control plane of the provider network upon customer request. 361 Note that the ITU-T allows the second categorization of service type 362 to embrace a variety of control plane types. 364 4.1.1 L1VPN for Dynamic Layer 1 Provisioning 366 Private network services in the second category (above) can be 367 enhanced so that multiple private networks are supported across the 368 layer 1 network as virtual private networks. These are Layer 1 369 Virtual Private Networks (L1VPNs). Note the first category (above) 370 would include L1VPNs with only two CEs as a special case. 372 Compared to the first category of service, the L1VPN service has 373 features such as connectivity restriction, a separate policy per VPN, 374 and distribution of membership information. 376 4.2 Merits of L1VPN 378 4.2.1 Customer Merits 380 From the customer's perspective, there are two main benefits to a 381 L1VPN. These benefits apply over and above the advantages of access 382 to a dynamically provisioned network. 384 - The customer can outsource the direct management of an optical 385 network by placing the VPN management in the control of a third 386 party. This frees the customer from the need to configure and 387 manage the connectivity information for the CEs that participate 388 in the VPN. 390 - The customer can make small-scale use of an optical network. So, 391 for example, by sharing access to the optical network with many 392 other users, the customer sites can be connected together across 393 the optical network without bearing the full cost of deploying 394 and managing the optical network. 396 To some extent, the customer may also gain from the provider's 397 benefits (see below). That is, if the provider is able to extract 398 more value from the layer 1 network, and provide better 399 differentiated services, the customer will benefit from lower 400 priced services that are better tailored to the customer's needs. 402 4.2.2 Provider Merits 404 The provider benefits from the customer's perception of benefits. 406 In particular, the provider can build on dynamic, on-demand services 407 by offering new VPN services and off-loading the CE-to-CE 408 configuration requirements from the customers. 410 Additionally, a more flexible VPN structure applied to the optical 411 network allows the provider to make more comprehensive use of the 412 spare (that is, previously unused) resources within the network. In 413 particular, since the PE could be responsible for routing the 414 connection through the optical network, the optical network can 415 reclaim control of how resources are used and adjust the paths so 416 that optimal use is made of all available resources. 418 4.3 L1VPN Deployment Scenarios 420 In large carrier networks providing various kinds of service, it is 421 often the case that multiple service networks are supported over a 422 shared transport network. L1VPNs are expected to support this type of 423 network architecture. Namely, by applying L1VPNs, multiple internal 424 service networks (which may be managed and operated separately) can 425 be supported over a shared layer 1 transport network controlled and 426 managed by GMPLS. In addition, L1VPNs can support capabilities to 427 offer innovative services to external clients. 429 Some more specific deployment scenarios are as follows. 431 4.3.1 Multi-Service Backbone 433 A multi-service backbone is characterized in terms such that each 434 service department of a carrier that receives the carrier's L1VPN 435 service provides a different kind of higher-layer service. The 436 customer receiving the L1VPN service (i.e., each service department) 437 can offer its own services whose payloads can be any layer (e.g., 438 ATM, IP, TDM). From the L1VPN service provider's point of view, these 439 services are not visible and are not part of the L1VPN service. That 440 is, the type of service being carried within the layer 1 payload is 441 not known by the service provider. 443 The benefit is that the same layer 1 core network resources are 444 shared by multiple services. A large capacity backbone network (data 445 plane) can be built economically by having the resources shared by 446 multiple services usually with flexibility to modify topologies, 447 while separating the control functions. Thus, each customer can 448 select a specific set of features that are needed to provide their 449 own service. 451 Note that it is also possible to control and manage these service 452 networks and the layer 1 core network by using GMPLS as a unified 453 control plane, instead of using L1VPNs. However, using L1VPNs is 454 beneficial in the following points. 456 - Independent address space for each of the service networks. 457 - Network isolation (topology information isolation, fault isolation 458 among service networks). 459 - Independent layer 1 resource view for each of the service networks. 460 - Independent policies that could be applied for each of the service 461 networks. 463 4.3.2 Carrier's Carrier 465 A carrier's carrier is characterized in terms such that one carrier 466 that receives another carrier's L1VPN service provides its own 467 services. In this scenario, two carriers may be in different 468 organizations (or may be separately managed within the same 469 organization). It is, therefore, expected that the information 470 provided at the service demarcation points is more limited than in 471 the multi-service backbone case. Similarly, less control of the 472 L1VPN service is given at the service demarcation points. For 473 example, customers of an L1VPN service receive: 475 - A more limited view of the L1VPN service provider network. 476 - More limited control over the L1VPN service provider network. 478 One of the merits is that each carrier can concentrate on a specific 479 service. For example, the customer of the L1VPN service may focus on 480 L3 services, e.g., providing secure access to the Internet, leaving 481 the L1VPN provider to focus on the layer 1 service, e.g., providing a 482 long haul bandwidth between cities. The L1VPN customer can construct 483 its own network using layer 1 resources supplied by the L1VPN 484 provider, usually with flexibility to modify topologies, and utilize 485 dedicated control plane functionalities. 487 4.3.3 Layer 1 Resource Trading 489 In addition to the scenarios where the second tier service provider 490 is using a single core service provider as mentioned above, it is 491 possible for the second tier provider to receive services from more 492 than one core service provider. In this scenario, there are some 493 benefits for the second tier service provider such as route 494 redundancy and dynamic carrier selection based on the price. 496 The second tier service provider can support a function that enables 497 a layer 1 resource trading service. Using resource information 498 published by its core service providers, a second tier service 499 provider can decide how to best use the core providers. For example, 500 if one core service provider is no longer able to satisfy requests 501 for service, an alternate service provider can be used. Or the second 502 tier service provider could choose to respond to price changes over 503 time. 505 Another example of second tier service provider use is to reduce 506 exposure to failures in each provider (i.e., to improve 507 availability). 509 4.3.4 Inter-SP L1VPN 511 In addition to the scenarios where a single connection between two 512 CEs is routed over a single service provider, it is possible that a 513 connection is routed over multiple service providers. This service 514 scenario is called Inter-SP L1VPN. 516 This scenario can be used to construct a single L1VPN from services 517 provided by multiple regional providers. There could be a variety 518 of business relationships among providers and customers. 520 4.3.5 Other Scenarios 522 There could be more complex L1VPN scenarios such as the case where 523 one or both CE-PE links of a L1VPN connection are not static, but are 524 based on L1VPN connections in their own right provided by the same or 525 different L1VPN service provider. 527 5. Reference Models 529 Figure 5.1 describes the L1VPN reference model. 531 +--------------------------------+ 532 | | 533 | +------------+ | : +------+ 534 | | Management | | : | CE | 535 | | system(s) | | : |device| 536 | +------------+ +------+ : | of | 537 | | |==:=|VPN A| 538 | | | : +------+ 539 +------+ : | L1 +------+ | PE | : +------+ 540 | CE | : | connection | | |device| : | CE | 541 |device| : +------+ +------+ | P |==| | : |device| 542 | of |=:==| |=======| |===|device| | |--:-| of | 543 |VPN A| : | | | | | | +------+ : |VPN B| 544 +------+ : | PE | | P | +------+ | : +------+ 545 +------+ : |device| |device| +------+ | : +------+ 546 | CE | : | | | | | | +------+ : | CE | 547 |device|=:==| |=======| |===| P | | |--:-|device| 548 | of | : +------+ +------+ |device|==| | : | of | 549 |VPN B| : | | | | PE | : |VPN A| 550 +------+ : | +------+ |device| : +------+ 551 : | | | : +------+ 552 : | | |==:=| CE | 553 : | +------+ : |device| 554 : | | : | of | 555 : | | : |VPN B| 556 : | | : +------+ 557 Customer | | Customer 558 interface | | interface 559 +--------------------------------+ 560 |<------ Provider network ------>| 561 | | 563 Figure 5.1: L1VPN reference model 565 In a L1VPN, layer 1 connections are provided between CEs' data plane 566 interfaces within the same VPN. In Figure 5.1, a connection is 567 provided between the left-hand CE of VPN A and the upper right-hand 568 CE of VPN A, and another connection is provided between the left-hand 569 CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark). 570 These layer 1 connections are called VPN connections. 572 5.1 Management Systems 574 As shown in the reference model, a provider network may contain one 575 or more management systems. A management system may support functions 576 including provisioning, monitoring, billing and recording. Provider 577 management systems may also communicate with customer management 578 systems in order to provide services. 580 6. Generic Service Description 582 This section describes generic L1VPN services. More detailed service 583 descriptions are provided through specific service models in section 584 7. 586 6.1 CE Construct 588 - The CE device may support more than one customer VPN. 589 - CE-PE data plane links (between data plane interfaces) may be 590 shared by multiple VPNs. 592 Note that it is necessary to disambiguate control plane messages 593 exchanged between CE and PE if the CE-PE relationship is applicable 594 to more than one VPN. This makes it possible to determine to which 595 VPN such control plane messages apply. Such disambiguation might be 596 achieved by allocating a separate control channel to each VPN (either 597 using a separate physical channel, a separate logical channel (e.g., 598 IP tunnel), or using separate addressing) or by extending the 599 signaling and routing protocols to allow them to identify the correct 600 VPN. 602 6.2 Generic Service Features 604 L1VPN has the following two generic service features. 606 - Connectivity restriction: Layer 1 connectivity is provided to a 607 limited set of CEs' data plane interfaces, called VPN end points. 608 (This set forms the L1VPN membership.) 610 - Per VPN control and management: Some level of control and 611 management capability is provided to the customer. Details differ 612 depending on service models described in section 7. 614 7. Service Models 616 This section describes Layer 1 VPN service models that can be 617 supported by Generalized MPLS (GMPLS) protocols enabled networks. 618 These models are derived from the generic service description 619 presented above. 621 Such layer 1 networks are managed and controlled using GMPLS 622 signaling as described in [RFC3471] and [RFC3473], and GMPLS routing 623 as described in [GMPLS-ROUTING]. It must be understood that meeting 624 the requirements set out in this document may necessitate 625 modifications to the existing GMPLS protocols both for the control 626 plane within the layer 1 network and for service provisioning at the 627 edge of the network (CE and PE devices). Such modifications are 628 discussed in [L1VPN-APP]. A CE and a PE are connected by one or more 629 data links. The ends of each link are usually represented as 630 GMPLS-capable interfaces. 632 Note that in this document, service models are classified by the 633 semantics of information exchanged over the customer interface. 635 7.1 Management-based Service Model 637 Figure 7.1 describes the management-based service model. 639 +--------------------+ 640 | | 641 +----------+ | +----------+ | 642 | Customer | | | Provider | | 643 |Management| : | |Management| | 644 | system(s)|-:-----|----| system(s)| | 645 +----------+ : | +----------+ | 646 : | | 647 : | | 648 +----+ : +----+ +----+ +----+ : +----+ 649 | CE |-------:---| PE |----| P |----| PE |---:-------| CE | 650 +----+ : +----+ +----+ +----+ : +----+ 651 : | | : 652 : +--------------------+ : 653 : |<-Provider network->| : 654 Customer Customer 655 interface interface 657 Figure 7.1: Management-based service model 659 In this service model, customer management systems and provider 660 management systems communicate with each other. Customer 661 management systems access provider management systems to request 662 layer 1 connection setup/deletion between a pair of CEs. Customer 663 management systems may obtain additional information, such as 664 resource availability information and monitoring information, from 665 provider management systems. There is no control message exchange 666 between a CE and PE. 668 The provider network may be based on GMPLS. In this case, existing 669 protocols to meet this service model may need to be extended (e.g., 670 to support soft permanent connections). However, interfaces between 671 management systems are not within the scope of this document. 672 Interfaces between management systems and network devices controlled 673 by GMPLS may need to be studied further in [L1VPN-APP]. 675 7.2 Signaling-based Service Model (Basic Mode) 677 In this service model, the CE-PE interface's functional repertoire is 678 limited to path setup signalling only. The provider's network is not 679 involved in distribution of customer network's routing information. 681 7.2.1 Overlay Service Model 683 Figure 7.2 describes the Overlay service model. 685 +--------------------+ 686 | | 687 +----+ : +----+ +----+ : +----+ 688 | CE |-------:---| PE | | PE |---:-------| CE | 689 +----+ : +----+ +----+ : +----+ 690 : | | : 691 : +--------------------+ : 692 : |<-Provider network->| : 693 Customer Customer 694 interface interface 696 Figure 7.2: Overlay service model 698 In this service model, the customer interface is based on the GMPLS 699 UNI Overlay [GMPLS-UNI]. The CE requests layer 1 connection 700 setup/deletion to a remote CE. There is no routing between a CE and 701 PE. The CE does not receive routing information from remote customer 702 sites, nor routing information about the provider network. The CE's 703 interface may be assigned a public or private address, that 704 designates VPN end points. 706 There are various ways that customers perceive the provider network. 707 In one example, the whole provider network may be considered as one 708 node - the path specified and recorded in signaling messages reflects 709 this. Note that this is distinct from the Virtual Node service model 710 described in section 7.3.2 because such a model requires that the 711 network is represented to the VPN sites as a virtual node - that is, 712 some form of routing advertisement is implied, and this is not in 713 scope for the Signaling-based service model. 715 Note that in addition, there may be communication between customer 716 management system(s) and provider management system(s) in order to 717 provide detailed monitoring, fault information etc. to customers. 719 7.3 Signaling and Routing Service Model (Enhanced Mode) 721 In this service model, the CE-PE interface provides the signaling 722 capabilities as in the Basic Mode, plus permits limited exchange of 723 information between the control planes of the provider and the 724 customer to help such functions as discovery of reachability 725 information in remote sites, or parameters of the part of the 726 provider's network dedicated to the customer. 728 By allowing CEs to obtain reachability information, a so-called 729 N-square routing problem could be solved [GVPN]. 731 In addition, by using the received traffic engineering-based routing 732 information, a customer can use traffic engineering capabilities 733 within his portion of the provider network. For example, a customer 734 can set up two disjoint connections between a pair of CEs. Another 735 example is that a customer can request a connection between a pair of 736 devices within customer sites, and not necessarily between CEs, with 737 more effective traffic engineering. 739 As such, the customer interface is based on GMPLS signaling and 740 mechanisms to exchange reachability/TE information. Typically, a 741 routing protocol is used between a CE and PE, or more precisely 742 between a CE and the VPN routing context instantiated on the PE. Link 743 state routing information would be needed to implement the above two 744 example scenarios. Some scenarios may be satisfied with reachability 745 routing information only. 747 Note that this service model does not preclude the use of mechanisms 748 other than routing protocols to exchange reachability/TE information. 749 Details need to be studied in [L1VPN-APP]. 751 Note that in addition, there may be communication between customer 752 management system(s) and provider management system(s) in order to 753 provide detailed monitoring, fault information etc. to customers. 755 Four specific types of the Signaling and Routing service model are 756 the Overlay Extension service model, the Virtual Node service model, 757 the Virtual Link service model and the Per-VPN Peer service model, 758 depending on how customers perceive the provider network in routing 759 and signaling. 761 7.3.1 Overlay Extension Service Model 763 This service model is a slight extension from the Overlay service 764 model. In this service model, a CE receives a list of TE link 765 addresses to which it can request a VPN connection (a list of 766 addresses within the same VPN). This may include additional 767 information concerning these TE links (e.g., switching type). Note, 768 in the Overlay Extension service model, information a CE can receive 769 is limited to information about the CE-PE TE link. Mechanisms other 770 than routing could be used to exchange reachability/TE information 771 between the CE and the PE. 773 7.3.2 Virtual Node Service Model 775 Figure 7.3 describes the Virtual Node service model. 777 +--------------------+ 778 | | 779 +----+ : | | : +----+ 780 | CE |-------:-----| Virtual Node |-----:-------| CE | 781 +----+ : | | : +----+ 782 : | | : 783 : +--------------------+ : 784 : |<-Provider network->| : 785 Customer Customer 786 interface interface 788 Figure 7.3: Virtual Node service model 790 In this type of service model, the whole provider network is 791 represented as a virtual node (defined in section 2). The customer 792 perceives the provider network as one single node, i.e., a 793 Generalized Virtual Private Cross-Connect (GVPXC) [GVPN]. The CE 794 receives routing information about CE-PE links and remote customer 795 sites. 797 Note that in this service model, there must be one single virtual 798 node, and this virtual node must be connected with every CE in the 799 VPN. 801 7.3.3 Virtual Link Service Model 803 Figure 7.4 describes the Virtual Link service model. 805 +--------------------+ 806 | Virtual | 807 +----+ : +----+ link +----+ : +----+ 808 | CE |-------:---| PE |**************| PE |---:-------| CE | 809 +----+ : +----+ +----+ : +----+ 810 : | | : 811 : +--------------------+ : 812 : |<-Provider network->| : 813 Customer Customer 814 interface interface 816 Figure 7.4: Virtual Link service model 818 In this service model, a virtual link is constructed between PEs. 819 For the definition of a virtual link, please refer to terminology in 820 section 2. The CE receives routing information about CE-PE links, 821 remote customer sites, as well as virtual links. A special property 822 of the virtual links used in this service model is that the provider 823 network allocates data plane link resources for the exclusive use of 824 each virtual link. The TE attributes of a virtual link are determined 825 according to data plane link resources allocated to this virtual 826 link. Virtual links are an abstraction of the provider network to 827 customers for administrative purposes as well as to exclude 828 "unnecessary information". 830 Note that in this service model, both end points of each virtual link 831 must be a PE device. 833 7.3.4 Per-VPN Peer Service Model 835 Figure 7.5 describes the Per-VPN Peer service model. 837 +--------------------+ 838 | | 839 +----+ : +----+ +----+ +----+ : +----+ 840 | CE |-------:---| PE |----| P |----| PE |---:-------| CE | 841 +----+ : +----+ +----+ +----+ : +----+ 842 : | | : 843 : +--------------------+ : 844 : |<-Provider network->| : 845 Customer Customer 846 interface interface 848 Figure 7.5: Per-VPN Peer service model 850 In this service model, the provider partitions the TE links within 851 the provider network per VPN, and discloses per-VPN TE link 852 information to corresponding CEs. As such, a CE receives routing 853 information about CE-PE links, remote customer sites, as well as 854 partitioned portions of the provider network. 856 Note that PEs may advertise abstracted routing information about the 857 provider network to CEs for administrative purpose as well as to 858 exclude "unnecessary information". In other words, virtual links 859 may be constructed between two nodes where direct data links do 860 not exist, or virtual nodes may be constructed to represent multiple 861 physical nodes and links. 863 In the Per-VPN Peer service model, at least one virtual node 864 corresponding to P devices (one single P or a set of Ps) must be 865 visible to customers. 867 8. Service Models and Service Requirements 869 The service models mentioned in section 7 are related to which 870 information is exchanged between CE and PE. In addition, service 871 models differ in how data plane resources are allocated for each VPN. 873 Note that in the ITU-T documents, the term "U-Plane" is used instead 874 of "data plane". 876 o Data plane resource allocation 878 - Shared or dedicated: 880 Shared means that provider network data plane links are shared by 881 multiple (i.e., any or a specific set of) VPNs. (Data plane links 882 are dynamically allocated to a VPN when a VPN connection is 883 requested, and data plane links allocated to one VPN at one time 884 can be allocated to another VPN at another time.) 886 Dedicated means that provider network data plane links are 887 partitioned per VPN. (Data plane links are statically allocated 888 to one VPN and can not be used by other VPNs.) 890 o Information exchanged between CE and PE 892 - Signaling 893 - Membership information : A list of TE link addresses within the 894 same VPN (associated with VPN end points) 895 - Customer network routing information 896 - Provider network routing information 898 Table 1 shows combination of service requirements and service models. 900 | Data plane | Data plane 901 | shared | dedicated 902 ---------------------------+------------------+------------------- 903 Signaling | Overlay | Overlay 904 ---------------------------+------------------+------------------- 905 Signaling + | Overlay | Overlay 906 Membership information | Extension | Extension 907 ---------------------------+------------------+------------------- 908 Signaling + | | 909 Membership information + | Virtual Node | Virtual Node 910 Customer network routing | | 911 information | | 912 ---------------------------+------------------+------------------- 913 Signaling + | | 914 Membership information + | | Virtual Link 915 Customer network routing | Not applicable | 916 information + | | Per-VPN Peer 917 Provider network routing | | 918 information | | 920 Table 1: Combination of service requirements and service models 922 As described in previous sections, the difference between the Virtual 923 Link service model and the Per-VPN Peer service model is whether 924 customers have visibility of P devices. In the Virtual Link service 925 model, the end points of virtual links must be PE devices, thus P 926 devices are not visible to customers. In the Per-VPN Peer service 927 model, at least one virtual node corresponding to P devices (one 928 single P, or a set of Ps) is visible to customers. 930 Note that when provider network routing information is provided to 931 customers, customers must be able to specify explicit links for a VPN 932 connection over the provider network. 934 8.1 Detailed Service Level Requirements 936 More detailed service requirements are provided below. They are 937 generally common to the various service models, except where 938 indicated. 940 - Selection of layer 1 class of service: Customers MAY be allowed to 941 specify a layer 1 class of service (e.g., availability level) for a 942 VPN connection. 944 - Reception of performance information: Customers MAY be allowed to 945 receive performance information for their VPN connections (e.g., 946 performance monitoring data). When data plane links are dedicated, 947 customers MAY be allowed to receive performance information for 948 links dedicated to them. 950 - Reception of fault information: Customers MAY be allowed to receive 951 fault information for their VPN connections (e.g., failures, data 952 plane alarms, rejections). When data plane links are dedicated, 953 customers MAY be allowed to receive fault information for links 954 dedicated to them. 956 - Reception of connection information: Customers MAY be allowed to 957 receive information for current VPN connections. 959 - Reception of accounting information: Customers MUST be able to 960 receive accounting information for each VPN. 962 - Specification of policy: Customers MAY be allowed to specify 963 policies (e.g., path computation policies, recovery policies 964 including parameters) for each VPN. 966 - Security: The communication between the customer and the provider 967 MUST be secure. Further details are described in section 9. 969 - Filtering: Unnecessary information (e.g., information concerning 970 other VPNs) MUST NOT be provided to each customer. This applies 971 particularly to Signaling and Routing service models, but is also 972 relevant to Signaling-based service models and to Management-based 973 service models. Further details are described in section 9. 975 - Requests/indications for arbitrary CE-CE control plane information 976 delivery. All models that support routing exchanges MAY support the 977 exchange of arbitrary CE-CE control plane information passed from 978 CE to PE within routing protocol messages and delivered from PE to 979 CE at the other side of the core network. In addition, some 980 signaling models MAY allow directed signaling message exchange 981 between CEs for hierarchical or stitched LSPs over CE-CE LSP. 983 9. Security Considerations 985 Security is clearly one of the essential requirements in L1VPNs. In 986 this section, key security requirements are highlighted. Security 987 considerations for L3VPNs and L2VPNs are described in existing 988 documents, such as [L3VPN-FRAME] and [L2VPN-FRAME]. These security 989 considerations should also be applied in L1VPNs, and these aspects 990 are described in this section. In addition, there are some specific 991 security considerations for L1VPNs, such as connectivity restriction 992 and shared control links. 994 This section first describes types of information to be secured. 995 Then, security features or aspects are described. Finally, some 996 considerations concerning scenarios where security mechanisms are 997 applied is described. 999 9.1 Types of Information 1001 It MUST be possible to secure the information exchanged between the 1002 customer and the provider. This includes data plane information, 1003 control plane information and management plane information. At layer 1004 1, data plane information is normally assumed to be secured once 1005 connections are established, since those connections are dedicated to 1006 each VPN. In L1VPNs, VPN connections MUST be restricted to be used 1007 only within the same VPN, as described in section 6.2. Note that a 1008 customer may wish to assure data plane information security against 1009 not only other customers, but also the provider. In such case, the 1010 customer may wish to apply their own security mechanisms for data 1011 plane information (CE-CE security), as later described. 1013 In addition, information contained in the provider network MUST be 1014 secured. This includes VPN service contract information, current VPN 1015 connection information, VPN membership information, and system 1016 information. Note these types of information MAY be accessible to 1017 authorized entities. 1019 9.2 Security Features 1021 Security features include the following: 1023 o Data integrity 1025 The information exchanged between the customer and the provider 1026 MUST be delivered unchanged. 1028 o Confidentiality 1030 The information exchanged between the customer and the provider 1031 MUST NOT be retrieved by the third party. 1033 o Authentication 1035 The entity requesting the service to the provider MUST be 1036 identified. 1038 o Access control 1040 Access to the information contained in the provider network MUST be 1041 restricted to the authorized entity. 1043 9.3 Scenarios 1045 There are two scenarios (or occasions) in which security mechanisms 1046 are applied. One is the service contract phase, where security 1047 mechanisms are applied once. The other is the service access phase, 1048 where security mechanisms are applied every time the service is 1049 requested. 1051 o Service contract scenario (static) 1053 This scenario includes the addition of new physical devices, such 1054 as CE devices, data links and control links. It MUST be guaranteed 1055 that these physical devices are connected to the right entity. In 1056 addition, authority to access specific information MAY be given to 1057 each customer as a part of service contract. 1059 o Service access scenario (dynamic) 1061 This scenario includes the reception of connection requests, 1062 routing information exchange requests, and management information 1063 retrieval requests. If a communication channel between the customer 1064 and the provider (control channel, management interface) is 1065 physically separate per customer, and the entity connected over 1066 this communication channel is identified in the service contract 1067 phase, the provider can ensure who is requesting the service. Also, 1068 the communication channel could be considered as secure. However, 1069 when communication channel is physically shared among customers, 1070 security mechanisms MUST be available and SHOULD be enforced. Note 1071 that even in the case of physically separate communication 1072 channels, customers may wish to apply security mechanisms, such as 1073 IPsec, to assure higher security, and such mechanisms MUST be 1074 available. 1076 When the entity requesting the service is identified, the provider 1077 MUST ensure that the request is authorized for that entity. This 1078 includes assuring that connection request is between VPN end points 1079 belonging to the same VPN. 1081 Also note that customers may wish to apply their own security 1082 mechanisms for data plane information (CE-CE security). This 1083 includes IPsec for IP traffic. 1085 10. Acknowledgements 1087 The material in this document is based on the work of the ITU-T Study 1088 Group 13. 1090 We would like to thank Dimitri Papadimitriou, Deborah Brungard, 1091 Yakov Rekhter, Alex Zinin, Igor Bryskin and Adrian Farrel for their 1092 useful comments and suggestions. 1094 11. Normative References 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, March 1997. 1099 12. Informative References 1101 For information on the availability of this document, please see 1102 http://www.itu.int. 1104 [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic 1105 requirements and architecture elements, ITU-T 1106 Recommendation, September 2003. 1108 For information on the availability of this document, please see 1109 http://www.itu.int. 1111 [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and 1112 network architectures, ITU-T Recommendation, July 1113 2004. 1115 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 1116 "Multiprotocol label switching Architecture", RFC 1117 3031, January 2001. 1119 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 1120 Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions 1121 to RSVP for LSP Tunnels", RFC 3209, December 2001. 1123 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol 1124 Label Switching (GMPLS) Signaling Functional 1125 Description", RFC 3471, January 2003. 1127 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label 1128 Switching (GMPLS) Signaling - Resource ReserVation 1129 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1130 RFC 3473, January 2003. 1132 [RFC4026] Anderssion, L., and Madsen, T., "Provider Provisioned 1133 Virtual Private Network (VPN) Terminology", RFC 4026, 1134 March 2005. 1136 [GMPLS-UNI] Swallow, G., et al., "GMPLS UNI: RSVP Support for the 1137 Overlay Model", draft-ietf-ccamp-gmpls-overlay, work 1138 in progress. 1140 [GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (editors), "Routing 1141 Extensions in Support of Generalized MPLS", draft- 1142 ietf-ccamp-gmpls-routing, work in progress. 1144 [L2VPN-FRAME] Andersson, L., and Rosen, E. (editors), "Framework 1145 for Layer 2 Virtual Private Networks (L2VPNs)", 1146 draft-ietf-l2vpn-l2-framework, work in progress. 1148 [L3VPN-FRAME] Callon, R., and Suzuki, M. (editors), "A Framework 1149 for Layer 3 Provider Provisioned Virtual Private 1150 Networks", draft-ietf-l3vpn-framework, work in 1151 progress. 1153 [GVPN] Ould-Brahim, H., and Rekhter, Y. (editors), "GVPN 1154 Services: Generalized VPN Services using BGP and 1155 GMPLS Toolkit", draft-ouldbrahim-ppvpn-gvpn-bgpgmpls, 1156 work in progress. 1158 [L1VPN-APP] T. Takeda (Ed.), "Applicability analysis of GMPLS 1159 protocols to Layer 1 Virtual Private Networks", 1160 draft-takeda-l1vpn-applicability, work in progress. 1162 13. Authors' Addresses 1164 Raymond Aubin 1165 Nortel Networks 1166 P O Box 3511 Station C 1167 Ottawa, ON K1Y 4H7 Canada 1168 Phone: +1 (613) 763 2208 1169 Email: aubin@nortelnetworks.com 1171 Marco Carugi 1172 Nortel Networks S.A. 1173 Parc d'activites de Magny-Chateaufort 1174 Les Jeunes Bois - MS CTF 32B5 - Chateaufort 1175 78928 YVELINES Cedex 9 - FRANCE 1176 Phone: +33 1 6955 7027 1177 Email: marco.carugi@nortelnetworks.com 1179 Ichiro Inoue 1180 NTT Network Service Systems Laboratories, NTT Corporation 1181 3-9-11, Midori-Cho 1182 Musashino-Shi, Tokyo 180-8585 Japan 1183 Phone: +81 422 59 6076 1184 Email: inoue.ichiro@lab.ntt.co.jp 1186 Hamid Ould-Brahim 1187 Nortel Networks 1188 P O Box 3511 Station C 1189 Ottawa, ON K1Y 4H7 Canada 1190 Phone: +1 (613) 765 3418 1191 Email: hbrahim@nortelnetworks.com 1193 Tomonori Takeda 1194 NTT Network Service Systems Laboratories, NTT Corporation 1195 3-9-11, Midori-Cho 1196 Musashino-Shi, Tokyo 180-8585 Japan 1197 Phone: +81 422 59 7434 1198 Email : takeda.tomonori@lab.ntt.co.jp 1200 14. Intellectual Property Consideration 1202 The IETF takes no position regarding the validity or scope of any 1203 Intellectual Property Rights or other rights that might be claimed 1204 to pertain to the implementation or use of the technology 1205 described in this document or the extent to which any license 1206 under such rights might or might not be available; nor does it 1207 represent that it has made any independent effort to identify any 1208 such rights. Information on the procedures with respect to 1209 rights in RFC documents can be found in BCP 78 and BCP 79. 1211 Copies of IPR disclosures made to the IETF Secretariat and any 1212 assurances of licenses to be made available, or the result of an 1213 attempt made to obtain a general license or permission for the use 1214 of such proprietary rights by implementers or users of this 1215 specification can be obtained from the IETF on-line IPR repository 1216 at http://www.ietf.org/ipr. 1218 The IETF invites any interested party to bring to its attention 1219 any copyrights, patents or patent applications, or other 1220 proprietary rights that may cover technology that may be required 1221 to implement this standard. Please address the information to the 1222 IETF at ietf-ipr@ietf.org. 1224 15. Full Copyright Statement 1226 Copyright (C) The Internet Society (2005). This document is subject 1227 to the rights, licenses and restrictions contained in BCP 78, and 1228 except as set forth therein, the authors retain all their rights. 1230 This document and the information contained herein are provided on an 1231 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1232 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1233 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1234 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1235 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1236 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.