Adrian Farrel | 1 Mar 2009 20:17
Picon

Re: Chair review of draft-ietf-ccamp-gmpls-mef-uni-01.txt

Thanks, Lou.

[SNIP]

>> Section 1
>>
>> Paragraph 1 doesn't seem sure how many frameworks there are.
>> Perhaps
>> OLD
>> [MEF6] and [G.8011] provide parallel frameworks
>> NEW
>> [MEF6] and [G.8011] provide parallel views of a framework
>
> humm, I think the original phrasing is more accurate.

Sorry, I wasn't clear.

The second sentence starts "The framework discusses ..."

Thus you need either my suggestion above, or to change to "The frameworks 
discuss ..."

All other changes look good, so we can pick this up when we have to take 
IETF/IESG comments.

Cheers,
Adrian 

Adrian Farrel | 1 Mar 2009 20:40
Picon

Re: Chair review of draft-ietf-ccamp-gmpls-ether-svcs-02.txt

Hi again, Lou.

[SNIP]

>> Section 2.1.1.1
>>
>> A CALL_ATTRIBUTES object containing an Endpoint ID TLV MAY be
>> included in the signaling messages of an LSP (connection) associated
>> with an established call. Such objects are processed according to
>> [4420BIS].
>>
>> As per our (elongated) discussion for the MLN extensions. I don't see
>> the value of including this object in a connection signaling message,
>> and I see some significant dangers (including a breach in the "need to
>> know" policy for the distribution of information within the Internet).
>>
>> But I have two issues with this paragraph.
>>
>> 1. You say "MAY be included", but nowhere in the spec do you
>> say why or what it might be used for. We are not in the habit of
>> defining mechanisms on the chance that they will be valuable at
>> some time in the future. If you have a specific use in mind, please
>> state it. Otherwise, we should delete this paragraph and let new
>> documents vary the rules when/if a use is found.
>>
> 
> I think the primary value is providing the operator/carrier with 
> additional OAM information on the LSP.
> 
>> 2. Draft 4420-bis (now RFC 5420) does not mention this object
(Continue reading)

Adrian Farrel | 1 Mar 2009 21:02
Picon

Re: Chair review of draft-ietf-ccamp-gmpls-dcsc-channel-ext-00.txt

And finally...

>> Section 3.2
>>
>> Subchannel: Variable
>>
>> See [RFC3471] for a description of this field. Note that this
>> field may not be 32 bit aligned.
>>
>> I think it is worth highlighting the context for the meaning and the
>> length of the subchannel ID
>>
> can you be more specific? I don't understand what you are asking for.

Yeah, OK, I didn't go and read the reference. Sorry.

>> Section 3.3
>>
>> Don't you think it is a layer of complexity too far to have a Label Set
>> made up of a set of Channel_Set Labels each made up of a series of
>> Channel_Set subobjects each made up of a set of channels?
>
> yes, this is a tad excessive.  I'm not sure why anyone would construct 
> such an object though...

Let's get rid of options.
It makes the code easier to write. Just because you don't create the object, 
doesn't mean you don't have to parse it.

See below...
(Continue reading)

Fatai Zhang | 3 Mar 2009 04:11
Favicon

New draft: draft-zhang-ccamp-rwa-wson-routing-ospf-00

 
Dear CCAMPers,
 
We just posted a new I-D: draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt.
 
Following the work on the RWA problem in the existing CCAMP drafts, and working with the protocol-independent encodings defined in   draft-ietf-ccamp-rwa-wson-encode, we have started work on OSPF extensions.  This work is at an early stage and we expect to revise the document over the next months.
 
Any comments are welcome.
 
The following is the abstract of this new I-D, please check out the attachment for details.

=========================================================================
Abstract

Wavelength switched optical networks (WSONs) are based on Wavelength Division Multiplexing (WDM) in which user traffic is carried by data channels of different optical wavelengths. In traditional WDM Networks, each wavelength path is statically configured. With the  deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), photonic cross-connects (PXCs), and tunable laser, WSONs have become more dynamic, and operators can flexibly set up wavelength paths to carry user traffic.

In WSONs where there are no or a limited number of switches capable of wavelength conversion paths must be set up subject to the wavelength continuity" constraint. This leads to a path computation problem known as routing and wavelength assignment (RWA). In order to
perform such computations, it is necessary to collect information about the available wavelengths within the network.

This document describes OSPF routing protocols extensions to support Wavelength Switched Optical Networks (WSON) under the control of
Generalized MPLS (GMPLS).
 

Thanks
 
Fatai 
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Monday, March 02, 2009 3:47 PM
Subject: New Version Notification for draft-zhang-ccamp-rwa-wson-routing-ospf-00


A new version of I-D, draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository.

Filename: draft-zhang-ccamp-rwa-wson-routing-ospf
Revision: 00
Title: OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)
Creation_date: 2009-03-02
WG ID: Independent Submission
Number_of_pages: 17

Abstract:
Wavelength switched optical networks (WSONs) are based on Wavelength
Division Multiplexing (WDM) in which user traffic is carried by data
channels of different optical wavelengths. In traditional WDM
Networks, each wavelength path is statically configured. With the
 
 
 deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs),
photonic cross-connects (PXCs), and tunable laser, WSONs have become
more dynamic, and operators can flexibly set up wavelength paths to
carry user traffic.


In WSONs where there are no or a limited number of switches capable
of wavelength conversion paths must be set up subject to the
"wavelength continuity" constraint. This leads to a path computation
problem known as routing and wavelength assignment (RWA). In order to
perform such computations, it is necessary to collect information
about the available wavelengths within the network.

This document describes OSPF routing protocols extensions to support
Wavelength Switched Optical Networks (WSON) under the control of
Generalized MPLS (GMPLS).

Conventions used in this document

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


The IETF Secretariat.

Network work group                                           Fatai Zhang 
Internet Draft                                                    Huawei 
Intended status: Standards Track                            G. Bernstein    
Expires: September 2009                                Grotto Networking
                                                               Young Lee  
                                                                  Dan Li
                                                             Jianrui Han 
                                                                  Huawei 
                                                          March 02, 2009 

                                      
            OSPF Extensions in Support of Routing and Wavelength 
      Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) 

                                      
              draft-zhang-ccamp-rwa-wson-routing-ospf-00.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with   
   the provisions of BCP 78 and BCP 79. 

   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. 

   This Internet-Draft will expire on September 02, 2009. 

Abstract 

   Wavelength switched optical networks (WSONs) are based on Wavelength 
   Division Multiplexing (WDM) in which user traffic is carried by data 
   channels of different optical wavelengths. In traditional WDM 
   Networks, each wavelength path is statically configured. With the 

 

<Zhang>               Expires September 2, 2009               [Page 1] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 
   photonic cross-connects (PXCs), and tunable laser, WSONs have become 
   more dynamic, and operators can flexibly set up wavelength paths to 
   carry user traffic.   

   In WSONs where there are no or a limited number of switches capable 
   of wavelength conversion paths must be set up subject to the 
   "wavelength continuity" constraint. This leads to a path computation 
   problem known as routing and wavelength assignment (RWA). In order to 
   perform such computations, it is necessary to collect information 
   about the available wavelengths within the network. 

   This document describes OSPF routing protocols extensions to support 
   Wavelength Switched Optical Networks (WSON) under the control of 
   Generalized MPLS (GMPLS). 

Conventions used in this document 

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

Table of Contents 

    
   1. Introduction.................................................3 
   2. Node Information.............................................3 
      2.1. Connectivity Matrix.....................................4 
         2.1.1. Link Set...........................................5 
      2.2. Wavelength Converter Pool Information...................7 
   3. Link Information.............................................7 
      3.1. WSON Port Wavelength Restrictions.......................8 
      3.2. Wavelength Availability Information.....................9 
      3.3. Shared Backup Wavelengths..............................11 
   4. Procedures for Routing Flooding.............................11 
   5. Security Considerations.....................................12 
   6. IANA Considerations.........................................12 
      6.1. Node Information.......................................12 
      6.2. Link Information.......................................12 
   7. References..................................................12 
   8. Authors' Addresses..........................................15 
   Acknowledgment.................................................16 

 

Zhang                  Expires September 2009                 [Page 2] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

1. Introduction 

   Wavelength switched optical networks (WSONs) are based on Wavelength 
   Division Multiplexing (WDM) in which user traffic is carried by data 
   channels of different optical wavelengths. In traditional WDM 
   Networks, each wavelength path is statically configured. With the 
   deployment of Reconfigurable Optical Add-Drop Multiplexers (ROADMs), 
   photonic cross-connects (PXCs), and tunable laser, WSONs have become 
   more dynamic, and operators can flexibly set up wavelength paths to 
   carry user traffic.  

   In WSONs where there are no or a limited number of switches capable 
   of wavelength conversion paths must be set up subject to the 
   "wavelength continuity" constraint. This leads to a path computation 
   problem known as routing and wavelength assignment (RWA). In order to 
   perform such computations, it is necessary to collect information 
   about the available wavelengths within the network. 

   [WSON-Frame] provides a framework for applying GMPLS [RFC3945] and 
   the Path Computation Element (PCE) architecture [RFC4655] to the 
   control of WSONs to address the RWA problem. [WSON-Info] describes an 
   information model that specifies the information needed at various 
   points in a WSON in order to compute paths and establish Label 
   Switched Paths (LSPs). Based on the information model of [WSON-Info], 
   [WSON-Encode] provides efficient protocol-independent encodings of 
   the information needed by the RWA process in a WSON. Such encodings 
   can be used to extend GMPLS signaling and routing protocols.    

   Therefore, in order to enable GMPLS to control WSON networks, this 
   document follows on from [WSON-Info], [WSON-Encode], and [WSON-IGP-
   Eval] to define extensions to the OSPF routing protocol to enhance 
   the Traffic Engineering (TE) properties of GMPLS TE which are defined 
   in [RFC3630], [RFC4202], and [RFC4203]. 

   No consideration of optical impairment routing related information is 
   included in this document. 

2. Node Information 

   According to [WSON-Info] and [WSON-Encode], the node information 
   about WSON nodes includes Node ID, connectivity matrix, wavelength 
   converter pool information. Except for the Node ID which should 
   comply with Routing Address described in [RFC3630], the other pieces 
   of information are defined in this document. 

   [OSPF-Node] defines a new top TLV named the Node Attribute TLV which 
   carries attributes related to a router/node. Connectivity matrix, 

 
Zhang                  Expires September 2009                 [Page 3] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   wavelength converter pool information are attributes associated with 
   a WSON node, so this document defines the following sub-TLVs of Node 
   Attribute TLV: 

   (1)Connectivity matrix sub-TLV 

   (2)Wavelength converter pool information sub-TLV 

2.1. Connectivity Matrix 

   Unlike the packet and TDM networks whose switching devices are 
   symmetric, the switching devices in a WSON are highly asymmetric. 
   Therefore, it is necessary to identify which ingress ports and 
   wavelengths can be connected to (the same wavelength on) a specific 
   egress port. Detailed descriptions of the Connectivity Matrix can be 
   found in the corresponding sections of [WSON-Info] and [WSON-Encode]. 

   The Connectivity Matrix TLV is a sub-TLV (the type is TBD by IANA) of 
   the Node Attribute TLV. The format of this sub-TLV is defined as 
   follows: 

       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Connectivity  |              Reserved                         | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        Link Set A #1                          | 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                        Link Set B #1                          | 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     Additional Link set pairs as needed       | 
      :                     to specify connectivity                   : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Type = TBD 

   Connectivity : 8 bits 

       The following values are currently defined. All other values are 
   reserved and SHOULD be transmitted as zero and ignored on receipt. 

       0x01: Fixed Connectivity Matrix 

 
Zhang                  Expires September 2009                 [Page 4] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       Indicates that the switching element is a kind of fixed switching 
   device, so the connectivity matrix represents the potential 
   connectivity matrix. This applies to asymmetric fixed devices or to 
   the fixed part of a "hybrid" device [Switch]. 

       0x02: Switched Connectivity Matrix 

       Indicates that the switching element is a kind of switched device 
   (e.g., ROADM or OXC). The connectivity matrix represents the 
   potential connectivity matrix for an asymmetric switch. 

   Reserved: 24 bits 

       This field is reserved. It SHOULD be set to zero on transmission 
   and MUST be ignored on receipt. 

   Link Set: At least one Link Set MUST be present. Multiple Link Sets 
   MAY be present. Each one has variable length. The Link set is defined 
   in Section 2.2.1.. 

2.1.1. Link Set   

       Link Set identifies a link group and is defined as follows: 

       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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Action     |Dir|  Format   |    Num Links  |    Reserved   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Link Identifier 1                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      :                               :                               : 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                       Link Identifier N                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Link Set is not a kind of sub-TLV and it is just a part of the 
   Connectivity Matrix TLV. (Note that this construct may be reused in 
   the Wavelength Converter Pool information in Section 2.3 in a future 
   version of this document.) 

   Action: 8 bits 

       The following values are currently defined. All other values are 
   reserved.   

 
Zhang                  Expires September 2009                 [Page 5] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       0x01: Inclusive List 

       Indicates that one or more link identifiers are included in the 
   Link Set. Each identifies a separate link that is part of the set. 

       0x02: Inclusive Range 

       Indicates that the Link Set defines a range of links.  It 
   contains two link identifiers. The first identifier indicates the 
   start of the range (inclusive). The second identifier indicates the 
   end of the range (inclusive). All links with numeric values between 
   the bounds are considered to be part of the set. A value of zero in 
   either position indicates that there is no bound on the corresponding 
   portion of the range. Note that the Action field could be set to 
   0x02(Inclusive Range) only when unnumbered link identifier is used. 

   Directionality of the Link Set (Dir): 2 bits 

       The following values are currently defined. All other values are 
   reserved.   

       0x01: Bidirectional 

       Indicates that the links in the Link Set are bidirectional. 

      0x02: Incoming 

       Indicates that the links in the Link Set are from the incoming 
   direction with respect to the node advertising the information. 

      0x03: Outgoing 

       Indicates that the links in the Link Set are to the outgoing 
   direction with respect to the node advertising the information. 

   Format: 6 bits 

   This field identifies the format of the link identifier. The 
   following values are currently defined. All other values are reserved. 

      0x01: Link Local Identifier with IPv4 address 

       Indicates that the links in the Link Set are identified by link 
   local identifiers which are IPv4 numbered. All link local identifiers 
   are supplied in the context of the advertising node. 

      0x02: Link Local Identifier with unnumbered interface 

 
Zhang                  Expires September 2009                 [Page 6] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       Indicates that the links in the Link Set are identified by link 
   local identifiers which are unnumbered interface IDs. All link local 
   identifiers are supplied in the context of the advertising node. 

   Num Links: 8 bits 

   This field indicates the total number of the links in the Link Set. 

   Reserved: 8 bits  

       This field is reserved. It MUST be set to zero on transmission 
   and MUST be ignored on receipt.  

   Link Identifier: 32 bits for each link 

      If the Format field is set to 0x01 (Link Local Identifier with 
   IPv4 address), the link identifier is the interface IP address used 
   to identify the incoming or outgoing port corresponding to the link. 
   The format of the Link Identifier should comply with the format of 
   the Local/Remote Interface IP Address described in [RFC3630].  

       If the Format field is set to 0x02 (Link Local Identifier with 
   unnumbered interface), the link identifier is unnumbered. 

   An example about Connectivity Matrix representation could be referred 
   to the Section 3.2 of [WSON-Encode]. 

2.2. Wavelength Converter Pool Information 

     TBD. 

3. Link Information 

   The most common link sub-TLVs are already defined in [RFC3630], 
   [RFC4203]. For example, Link ID, Administrative Group, Interface 
   Switching Capability Descriptor (ISCD), Link Protection Type, Shared 
   Risk Link Group Information (SRLG), and Traffic Engineering Metric.  

   For WSONs, per [WSON-Info] and [WSON-Encode], the following 
   additional link sub-TLVs are defined in this document. 

   (1) WSON Port Wavelength Restrictions sub-TLV 

   (2) Wavelength Availability sub-TLV 

   (3) Shared Backup Wavelengths sub-TLV 

 

Zhang                  Expires September 2009                 [Page 7] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

3.1. WSON Port Wavelength Restrictions 

   In WSONs, there may be wavelength restrictions on a link or port. For 
   example, a WSON link might only be able to support switching some 
   specific wavelengths. These restrictions are distributed by OSPF to 
   be convenient for wavelength path computation. 

   The WSON Port Wavelength Restrictions TLV is a sub-TLV (the type is 
   TBD by IANA) of the Link TLV. The format of this sub-TLV is defined 
   as follows: 

       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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |RestrictionKind|T|  Reserved   |       MaxNumChannels          | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
     |                     Wavelength Set                            |  
     |                      (variable)                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Type = TBD 

   RestrictionKind: 8 bits 

       The following values are currently defined. All other values are 
   reserved.   

       0x01: Simple wavelength selective restriction 

       In this case, MaxNumChannels indicates the maximum number of 
   wavelengths permitted on the port, and the accompanying Wavelength 
   Set indicates the specific permitted wavelengths. 

       0x02: Waveband device with a tunable center frequency and 
   passband. 

       In this case, MaxNumChannels indicates the maximum width of the 
   waveband in terms of the channels spacing given in the Wavelength Set. 
   The corresponding wavelength set is used to indicate the overall 
   tuning range. Specific center frequency tuning information can be 
   obtained from dynamic channel in use information. 

   MaxNumChannels indicates the maximum number of channels supported on 
   the port/waveband dependent on the setting of the RestrictionKind 
   field. 

 

Zhang                  Expires September 2009                 [Page 8] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   Wavelength Set information is carried as defined in Section 3.4 of 
   [WSON-Encode]. 

3.2. Wavelength Availability Information 

   The requirements for a global semantic for wavelength labels and the 
   corresponding standardized wavelength label can be found in [Lambda-
   Labels]. 

   Because the wavelength continuity along the wavelength Label Switched 
   Path (LSP) should be ensured without wavelength conversion or with 
   wavelength conversion at some switches along the path, the 
   information about wavelength availability and wavelength connectivity 
   is very important when computing a wavelength LSP. For example, if 
   the wavelength label range [lambda 1, lambda 5] of fiber 1 can be 
   connected to the same wavelength label range of fiber 2, but only 
   lambda 3 is available on fiber 2 because other wavelength labels are 
   occupied, lambda 3 must be selected on fiber 1.  

   If the wavelength availability information is not known by the node    
   performing the path computation, then the computation can only be   
   performed at the level of TE links, and wavelength assignment must be   
   resolved locally by the switches on a hop-by-hop basis enhanced by   
   signaling protocol mechanisms used to negotiate label selection.   
   However, this case may be very inefficient in the signaling protocol,   
   and can easily lead to blocking problems where a path is selected for   
   which there is no suitable wavelength availability, unless some or   
   all of the switches along the path are capable of full wavelength   
   conversion. In the general case of limited or no wavelength   
   conversion, information on wavelength availability is essential to    
   perform efficient and accurate path computation.  

   It is possible to consider reporting the statuses of each wavelength 
   on a link using implicit wavelength identification based on the link-
   local knowledge of wavelengths supported and a well-known sequence. 
   However, this information would be of no use in a wider context (i.e., 
   away from the link ends). On the other hand, if the standardized 
   label format described in [Lambda-Labels] is used to identify every 
   wavelength when its status is reported, the wavelength information 
   will be a little larger (or the order of one wavelength label per 
   status advertised). This may have a significant affect on the total 
   information advertised in a network because a WSON link often 
   supports many wavelengths (e.g., 80 or 160 wavelength systems).  

   To minimize the size of information, a bitmap wavelength set is 
   defined in [WSON-Encode] to indicate the wavelength availability 
   information for a fiber, i.e., only one bit is used to indicate the 

 
Zhang                  Expires September 2009                 [Page 9] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   status of a certain wavelength (the wavelength is either available or 
   not available).   

   Note that there are five approaches for Wavelength Set which is used 
   to represent the wavelength availability information described in 
   Section 3.4 of [WSON-Encode]. Considering that the continuity of the 
   available or unavailable wavelength set can be scattered for the 
   dynamic wavelength availability, so it may burden the routing to 
   reorganize the wavelength set information when the Inclusive 
   (/Exclusive) List (/Range) approaches are used to represent 
   wavelength availability information. Therefore, it is RECOMMENDED 
   that only the Bitmap Set be used for representation wavelength 
   availability information as follows. 

   The Wavelength Availability  TLV is a sub-TLV (the type is TBD by 
   IANA) of the Link TLV. The format of this sub-TLV is defined as 
   follows: 

       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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |          Num Wavelengths      |         Reserved              | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |Grid |  C.S. |     Reserved    |    n  for lowest frequency    | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |    Bit Map Double-word #1 (Lowest frequency channels)         | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     :                                                               : 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |Bit Map Double-word #N (Highest frequency channels)|Padded bits| 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Type = TBD 

   The three fields (Grid, C.S. and n) are defined in [Lambda-Label]. 

   Num Wavelengths: 8 bits 

       Indicates the number of the wavelengths represented by the bit 
   map.  

   Each bit in the bit map represents a particular frequency with a 
   value of 1/0 indicating whether the frequency is available or not. 
   Bit position zero represents the lowest frequency, while each 
   succeeding bit position represents the next frequency a channel 
   spacing (C.S.) above the previous. The values of the bit map are 
   defined as follows: 

 
Zhang                  Expires September 2009                [Page 10] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

       1 = Available  

       0 = Assigned (in use, or failed, or administratively down, or 
   under testing)  

   The valid length of the bit map is clearly Num Wavelengths bits, but 
   the bit map should be padded to make the whole number of the bits in 
   bitmap be the time of 32 bits so that the TLV is a multiple of four 
   bytes. Padded bit SHOULD be set to 0 and MUST be ignored. 

   Bits that do not represent wavelengths (i.e., those in positions (Num 
   Wavelengths - 1) and beyond) SHOULD be set to zero and MUST be 
   ignored.  

3.3. Shared Backup Wavelengths 

   TBD. 

4. Procedures for Routing Flooding 

   The advertisement for the node attributes SHOULD comply with the 
   procedures described in [OSPF-Node]. 

   In the WSON networks, the node information can be classified as two 
   kinds: one is static information comparatively such as Node ID, 
   Connectivity Matrix information; the other is dynamic information 
   such as Wavelength Converter Pool Status information. For the static 
   node information, the router announces the static node information in 
   the node attribute TLV which could be advertised during the node 
   starts or periodically for some configurable time (e.g., per hour or 
   several hours). For the dynamic node information, the router 
   announces this information in the separate node attribute TLV which 
   SHOULD be advertised during node starts or when the corresponding 
   node information is changed. 

   For the WSON link information, the procedures for the routing 
   flooding SHOULD comply with [RFC3630], [RFC4203] and the other 
   existing family standards, and there is no extended process for the 
   link attributes advertisement, except that some link sub-TLVs are 
   defined in this document. 

   Note that as with other TE information, an implementation SHOULD take 
   measures to avoid rapid and frequent updates of routing information 
   that could cause the routing network to become swamped. A threshold 
   mechanism MAY be applied such that updates are only flooded when a 

 
Zhang                  Expires September 2009                [Page 11] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   number of changes have been made to the wavelength availability 
   information within a specific time. Such mechanisms MUST be 
   configurable if they are implemented. 

5. Security Considerations 

   This document does not introduce any further security issues other   
   than those discussed in [RFC 3630], [RFC 4203]. 

6. IANA Considerations 

   [RFC3630] says that the top level Types in a TE LSA and Types for 
   sub-TLVs for each top level Types must be assigned by Expert Review, 
   and must be registered with IANA. 

   IANA is requested to allocate new Types for the sub-TLVs as defined 
   in Sections 2.1, 3.1, and 3.2 as follows: 

6.1. Node Information 

   This document introduces the following sub-TLV of Node Attribute TLV 
   (Value TBD, see [OSPF-Node]) 

   Type   sub-TLV 

   TBD    Connectivity matrix 

6.2. Link Information 

   This document introduces the following sub-TLV of TE Link TLV (Value 
   2) 

   Type   sub-TLV 

   TBD    WSON Port Wavelength Restrictions 

   TBD    Wavelength Availability 

7. References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Signaling Functional Description", RFC 3471, 
             January 2003. 

 

Zhang                  Expires September 2009                [Page 12] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   [RFC3630] Katz, D., Kompella, K., and Yeung, D., "Traffic                   
             Engineering (TE) Extensions to OSPF Version 2", RFC                
             3630, September 2003. 

   [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 
             in Support of Generalized Multi-Protocol Label Switching 
             (GMPLS)", RFC 4202, October 2005 

   [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in 
             Support of Generalized Multi-Protocol Label Switching 
             (GMPLS)", RFC 4203, October 2005.  

   [RFC3945] E. Mannie, Ed., "OGeneralized Multi-Protocol Label Switching (GMPLS) 
             Architecture", RFC 3945, October 2004.  

   [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path               
             Computation Element (PCE)-Based Architecture ", RFC 4655, 
             August 2006.  

   [OSPF-Node] R. Aggarwal and K. Kompella, "Advertising a Router's             
               Local Addresses in OSPF TE Extensions", draft-ietf-ospf-          
               te-node-addr, work in progress. 

   [Lambda-Labels] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, 
                    "Generalized Labels for G.694 Lambda-Switching 
                    Capable Label Switching Routers", work in progress: 
                    draft-ietf-ccamp-gmpls-g-694-lambda-labels-03.txt, 
                    January 2009. 

   [WSON-Frame] G. Bernstein, Y. Lee, W. Imajuku, "Framework for GMPLS 
                and PCE Control of Wavelength Switched Optical 
                Networks", work in progress: draft-ietf-ccamp-rwa-WSON-
                Framework-00.txt, December 2008. 

   [WSON-Info] Y. Lee, G. Bernstein, D. Li, W. Imajuku, "Routing and 
               Wavelength Assignment Information Model for Wavelength 
               Switched Optical Networks", work in progress: draft-ietf-
               ccamp-rwa-info-01.txt, October 2008. 

   [WSON-Encode]                     G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and 
                Wavelength Assignment Information Encoding for 
                Wavelength Switched Optical Networks", work in progress: 
                draft-ietf-ccamp-rwa-wson-encode-00.txt, December 2008. 

 

Zhang                  Expires September 2009                [Page 13] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   [WSON-IGP-Eval] Dan Li, J. Gao, Y. Lee, "Evaluation of Possible 
                    Interior Gateway Protocol Extensions for Wavelength 
                    Switching Optical Networks", work in progress: 
                    draft-li-ccamp-wson-igp-eval-01.txt, July 2008. 

    [Switch] G. Bernstein, Y. Lee, A. Gavler, J. Martensson, " Modeling         
             WDM Wavelength Switching Systems for use in Automated Path 
             Computation", http://www.grotto-   
             networking.com/wson/ModelingWSONswitchesV2a.pdf , June, 
             2008 

 

Zhang                  Expires September 2009                [Page 14] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

8. Authors' Addresses

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912 
   Email: zhangfatai <at> huawei.com

 
   Greg Bernstein
   Grotto Networking 
   Fremont CA, USA 

   Phone: (510) 573-2237 
   Email: gregb <at> grotto-networking.com

   Young Lee
   Huawei Technologies
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   USA

   Phone: (972) 509-5599 (x2240)
   Email: ylee <at> huawei.com

   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: danli <at> huawei.com

   Jianrui Han
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

 

Zhang                  Expires September 2009                [Page 15] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   Phone: +86-755-28972913
   Email: hanjianrui <at> huawei.com

Acknowledgment 

   TBD. 

Intellectual Property 

   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at ietf-ipr <at> ietf.org. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions of   
   these Legal Provisions that are published by third parties, including   
   those that are translated into other languages, should not be   
   considered to be definitive versions of these Legal Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect and   

 

Zhang                  Expires September 2009                [Page 16] 

Internet-Draft        OSPF Extensions for WSON              March 2009 

   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

 
Disclaimer of Validity 

   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

 
Full Copyright Statement 

   Copyright (c) 2009 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 in effect on the date of   
   publication of this document (http://trustee.ietf.org/license-info).   
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 

 

Zhang                  Expires September 2009                [Page 17] 

Fatai Zhang | 3 Mar 2009 04:36
Favicon

New draft: draft-zhang-ccamp-gmpls-call-extensions-00

Dear friends,
 
We just uploaded a new ID (draft-zhang-ccamp-gmpls-call-extensions-00), and the following is the abstract of this new ID.
 
Please check out the attached document for details.
 
We would welcome any comments.
 
 
=========================================================================
Abstract:

Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are used to support Calls. Although it is stated that these mechanisms are applicable to any environment (including multi-area), the "Call
Path" is determined hop-by-hop by each "Call Manager" in sequence along the path of the Call. 
  
However, it is desirable to allow the Call-initiator to identify the Call Path explicitly in some cases (especially in the multi-domain
case).

This document describes RSVP-TE signaling extensions to allow the Call-initiator to identify the Call Path explicitly when transit
nodes (besides the Call-initiator and Call-terminator) are involved in these Calls.
 
 
 

Thanks
 
Fatai
 
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935
----- Original Message -----
Sent: Monday, March 02, 2009 4:03 PM
Subject: New Version Notification for draft-zhang-ccamp-gmpls-call-extensions-00


A new version of I-D, draft-zhang-ccamp-gmpls-call-extensions-00.txt has been successfuly submitted by Fatai Zhang and posted to the IETF repository.

Filename: draft-zhang-ccamp-gmpls-call-extensions
Revision: 00
Title: RSVP-TE extensions to GMPLS Calls
Creation_date: 2009-03-02
WG ID: Independent Submission
Number_of_pages: 14

Abstract:
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are
used to support Calls. Although it is stated that these mechanisms
are applicable to any environment (including multi-area), the "Call
Path" is determined hop-by-hop by each "Call Manager" in sequence
along the path of the Call.

 
 
 However, it is desirable to allow the Call-initiator to identify the
Call Path explicitly in some cases (especially in the multi-domain
case).

This document describes RSVP-TE signaling extensions to allow the
Call-initiator to identify the Call Path explicitly when transit
nodes (besides the Call-initiator and Call-terminator) are involved
in these Calls.

Conventions used in this document

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


The IETF Secretariat.

Network work group                                           Fatai Zhang
Internet Draft                                                    Dan Li 
Intended status: Standards Track                             Jianhua Gao   
Expires: September 2009                                           Huawei 
                                                          March 02, 2009      

                                      
                     RSVP-TE extensions to GMPLS Calls 

                                      
              draft-zhang-ccamp-gmpls-call-extensions-00.txt 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with   
   the provisions of BCP 78 and BCP 79. 

   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. 

   This Internet-Draft will expire on September 02, 2009. 

Abstract 

   Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource 
   ReserVation Protocol-Traffic Engineering (RSVP-TE) extensions are 
   used to support Calls. Although it is stated that these mechanisms 
   are applicable to any environment (including multi-area), the "Call 
   Path" is determined hop-by-hop by each "Call Manager" in sequence 
   along the path of the Call. 

 

 
<Zhang>               Expires September 02, 2009               [Page 1] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   However, it is desirable to allow the Call-initiator to identify the 
   Call Path explicitly in some cases (especially in the multi-domain 
   case). 

   This document describes RSVP-TE signaling extensions to allow the 
   Call-initiator to identify the Call Path explicitly when transit 
   nodes (besides the Call-initiator and Call-terminator) are involved 
   in these Calls. 

Conventions used in this document 

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

Table of Contents 

    
   1. Introduction.................................................2 
   2. Motivation...................................................3 
   3. Solution.....................................................5 
   4. Operations...................................................8 
      4.1. User-Initiated Calls....................................8 
   5. Security Considerations......................................9 
   6. Manageability Considerations.................................9 
   7. IANA Considerations..........................................9 
      7.1. Call_ERO Object.........................................9 
      7.2. Call_RRO Object........................................10 
      7.3. RSVP Error Codes and Error Values......................10 
   8. Normative References........................................10 
   9. Authors' Addresses..........................................12 
   Acknowledgment.................................................12 

1. Introduction 

   The concept of a Generalized Multi-Protocol Label Switching (GMPLS) 
   Call is introduced in [RFC4974]. A Call is an association between 
   endpoints and possibly between key transit points (such as network 
   boundaries) in support of an instance of a service. The requirements 
   of Calls and the RSVT-TE extensions in support of Calls are also 
   described in [RFC4974]. 

   A Call is usually established between end-points to verify polices 
   and authorization applied on these end-points. However, in a multi-
   domain environment, some key polices and authorization are usually 

 
Zhang                 Expires September 01, 2009               [Page 2] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   deployed on the corresponding domain border nodes (domain ingress or 
   egress nodes), so these border nodes are also involved in processing 
   the Call when the Call is going through these domains. These nodes 
   that process the Call are known as "Call Managers". 

   Although it is stated that the mechanisms proposed in [RFC4974] are 
   applicable to any environment (including multi-area), the "Call Path" 
   is determined hop-by-hop by each Call Manager in sequence along the 
   path of the Call. That is, each Call Manager forwards the Notify 
   message that is used to manage the Call to the next Call Manager 
   along the Call Path. The Notify messages are targeted at (i.e., carry 
   the IP address of) the next Call Manager, and the route that the 
   messages follow through the network to reach the next Call Manager is 
   not important. 

   However, it is desirable to allow the Call-initiator to determine the 
   Call Path and to signal it explicitly in some cases (especially in 
   the multi-domain case). 

   This document describes RSVP-TE signaling extensions to allow the 
   Call-initiator to identify the Call Path explicitly when transit Call 
   Managers (besides the Call-initiator and Call-terminator) are 
   involved in a Call. 

   Note that Call and Connection are separated in the signaling, and 
   Call procedures do not impact the Connection procedures, so this 
   document does not modify any Connection procedures defined in 
   [RFC3471], [RFC3473], [RFC4208], and other existing protocol family. 

2. Motivation 

   In some cases, it is desirable to set up a Call through not only the 
   Call-initiator and Call-terminator, but also some transit Call 
   Manager nodes (e.g., transit border domain nodes) to verify the 
   corresponding polices and authorization applied on these nodes. 

   For instance, in the multi-domain case as shown in Figure 1, there 
   are three interconnected domains. Nodes I, D11, and D12 are in Domain 
   1, and the nodes D11 and D12 are the border nodes. Nodes D21, D22, 
   D23, and D24 are the border nodes of Domain 2, and the internal nodes 
   of Domain 2 are not shown in the figure. Nodes D31, D32, and E are in 
   Domain 3, and the nodes D31 and D32 are the border nodes. 

   Policies and authorization are often applied in domain border nodes, 
   such as the nodes D11, D12, D21, D22, D23, D24, D31, and D32 in this 
   example. Therefore, in this case, when a Call between Call-initiator 
   (node I) and Call-terminator (node E) is going to be setup, the Call 

 
Zhang                 Expires September 01, 2009               [Page 3] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   should be processed in some domain border nodes (for example, the 
   nodes D11, D21, D23, D31 should process the Call when the Call Path 
   I-D11-D21-D23-D31-E is selected).  

   Note that in this case, there may be several alternative Call Paths 
   between Call-initiator and Call-terminator. For example, in the 
   Figure 1, the possible Call paths may be I-D11-D21-D23-D31-E or I-
   D12-D22-D24-D32-E, or some other path depending on the 
   interconnectivity across the domains.  

       +------------------+  +----------------+  +-----------------+     
       |            +--+  |  |  +--+    +--+  |  |  +--+           |     
       |          --|  |--|--|--|  |----|  |--|--|--|  |--         |     
       |         /  |  |  |  |  |  |    |  |  |  |  |  |  \        |     
       |        /   +--+  |  |  +--+    +--+  |  |  +--+   \       |     
       |  +--+ /     D11  |  |   D21     D23  |  |   D31    \ +--+ |     
       |  |  |-           |  |                |  |           -|  | |     
       |  |  |-           |  |                |  |           -|  | |     
       |  +--+ \    +--+  |  |  +--+    +--+  |  |  +--+    / +--+ |     
       |   I    \   |  |  |  |  |  |    |  |  |  |  |  |   /   E   |     
       |         ---|  |--|--|--|  |----|  |--|--|--|  |---        |     
       |            +--+  |  |  +--+    +--+  |  |  +--+           |     
       |             D12  |  |   D22     D24  |  |   D32           |     
       |                  |  |                |  |                 |     
       +------------------+  +----------------+  +-----------------+     
            Domain1               Domain2             Domain3            

                      Figure 1: Multi-domain Scenario 

   Note that how to determine the Call Path is out of the scope of this 
   document.  

   According to the Section 7.3.1 of [RFC 4974], it is already supported 
   that the third parties (i.e., non-end points such as External Call 
   Managers) are involved in the Call, but there is no mechanisms for 
   the Call-initiator to control the Call Path. The Call Path is 
   determined by each Call Manager in turn selecting the next Call 
   Manager on the path to the Call-terminator and forwarding the Notify 
   message that sets up the Call. 

   However, in the case of a multi-domain Call, commercial and policy 
   motivations normally play a role in selecting the Call Path. This 
   selection may be at a coarse level (for example, identifying which 
   domains should or should not be used), or may be at a finer level 
   (for example, identifying which Call Managers to use). Note that 
   there is no concept of specifying links or resources within the Call 

 
Zhang                 Expires September 01, 2009               [Page 4] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Path as the Call is an ordered association of Call Managers, and not 
   a data path in the network. 

   Therefore, it is desirable to allow full control for the Call-
   initiator, which means that the Call-initiator can identify the full 
   Call Path explicitly. Moreover, the management plane needs to be able 
   to identify the Call Path explicitly as an instruction to the Call-
   initiator. 

   This document defines protocol extensions that provide a solution for 
   these requirements. 

3. Solution 

   In order to identify the Call Path explicitly for the Call-initiator, 
   the CALL_EXPLICIT_ROUTE object (Call_ERO) is introduced. 

   The format of the Call_ERO is defined as follows: 

   Class = TBD (0bbbbbbb), C_Type = 1 

 
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The format of the Call_ERO is the same as EXPLICIT_ROUTE object (ERO) 
   described in [RFC3209]. And the subobjects including IPv4 prefix, 
   IPv6 prefix, and autonomous system number defined in [RFC3209] could 
   be reused as subobjects of Call_ERO. 

   In inter-domain environment, it is possible to collect and 
   communicate information about the inter-domain links because the 
   domains usually don't share the Traffic Engineering (TE) information 
   between domains. So Call_RRO and its Link_Capability subobject are 
   introduced to record this information. 

   The format of the Call_RRO is defined as follows: 

   Class = TBD (11bbbbbb), C_Type = 1 

 

Zhang                 Expires September 01, 2009               [Page 5] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

 
    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 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                                                               | 
   //                        (Subobjects)                         // 
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The format of the Call_RRO is the same as RECORD_ROUTE object (RRO) 
   described in [RFC3209].  

   The subobjects of RRO including IPv4 address and IPv6 address defined 
   in [RFC3209] could be reused as subobjects of Call_RRO and the 
   formats of the subobjects for LINK_CAPABILITY object [RFC4974] 
   including type 1, type 2, type 4, type 64 and type 65 could be reused 
   as Link_Capability subobjects of Call_RRO (Note that the 
   corresponding types are redefined as type 3, type 4, type 5, type 64 
   and type 65).  

   The following subobjects are defined currently: 

      -  Type 1: IPv4 address subobject defined in Section 4.4.1.1 of 
                 [RFC3209]. 

      -  Type 2: IPv6 address subobject defined in Section 4.4.1.2 of 
                 [RFC3209]. 

      -  Type 3: the link local IPv4 address of a link or a numbered 
                 bundle using the format defined in [RFC3209]. 

      -  Type 4: the link local IPv6 address of a link or a numbered 
                 bundle using the format defined in [RFC3209]. 

      -  Type 5: the link local identifier of an unnumbered link or 
                 bundle using the format defined in [RFC3477]. 

      -  Type 64: the Maximum Reservable Bandwidth corresponding to this      
                  link or bundle (see [RFC4201]). 

      -  Type 65: the interface switching capability descriptor (see      
                  [RFC4202]) corresponding to this link or bundle (see 
                  also [RFC4201]). 

    

 
Zhang                 Expires September 01, 2009               [Page 6] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Similar to the Label RRO [RFC3209], the Link_Capability subobjects 
   are pushed onto the Call_RRO object prior to pushing on the IPv4 or 
   IPV6 subobject. A Call Manager MUST NOT push on a Link_Capability 
   subobject without also pushing on an IPv4 or IPv6 subobject. 

   Note that multiple Link_Capability subobjects following IPv4 or IPv6 
   subobject can be presented in the Call_RRO to collect all the 
   possible link information between domains. 

   The revised Notify message is as follows using the meta-language 
   described in [RBNF]: 

      <Notify message>  ::= <Common Header> [ <INTEGRITY> ] 

                            [[ <MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]...] 

                            [ <MESSAGE_ID> ] 

                            <ERROR_SPEC> 

                            <notify session list> 

   Where 

      <notify session list> ::= [ <notify session list> ] 

                                <notify session> 

      <notify session>  ::= <SESSION> [ <ADMIN_STATUS> ] 

                            [ <POLICY_DATA>...] 

                            [ <LINK_CAPABILITY> ] 

                            [ <SESSION_ATTRIBUTE> ] 

                            [ <Call_ERO> ] 

                            [ <Call_RRO> ] 

                            [ <sender descriptor> | <flow descriptor> ] 

   And where: 

      <sender descriptor> ::= see [RFC3473] 

      <flow descriptor> ::= see [RFC3473] 

 
Zhang                 Expires September 01, 2009               [Page 7] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

4. Operations 

   The processes for the revised Notify message comply with the 
   procedures described in [RFC3974] except that the Call_ERO is 
   processed at the Call Managers. The processes for the Call_ERO and 
   Call_RRO are similar to the Connection ERO and RRO [RFC3209].  

   The procedures of Call Setup for the revised Notify message are 
   summarized as follows (other procedures are the same as [RFC3974]): 

   (1)The Call-initiator initiates Call setup and processes the Call 
      locally (e.g., verifies the policy, etc.). After that, it adds 
      the Call_ERO to the Notify message, including the sub-objects to 
      identify the Call Path. If Call_RRO is required, it also should 
      add Call_RRO to the Notify message. Then the Call-initiator sends 
      the Notify message to the first Call Manager indicated by the 
      first sub-object of the Call_ERO (Note that there is no Label 
      _Recording for Call_RRO). 

   (2)The transit Call Managers process the Call when they receive the 
      Notify messages. After that, they remove themselves from the 
      Call_ERO. If Call_RRO is presented in the Notify message, it 
      should also process Call_RRO similar to [RFC3209]. Then it sends 
      the Notify message to the next Call Manager identified by the 
      Call_ERO. 

   (3)Step 2 recurs until the Notify message gets to the Call-
      terminator. And the corresponding Notify message returns to Call-
      initiator in the inverse direction. 

   If, at any time, the Call_ERO is absent or present but empty (for 
   example, when a transit Call Manager removes itself from the 
   Call_ERO), a Call Manager MUST select a next Call Manager on the Call 
   Path toward the Call-terminator (identified in the Session object of 
   the Notify message). This next Call Manager may be another transit 
   Call Manager or may be the Call-terminator itself. The Call Manager 
   MAY create a new Call_ERO if none exists to define hops to the Call-
   terminator, or may add hops to the existing Call_ERO between itself 
   and the next hop in the received Call_ERO. Such actions are subject 
   to local policy. 

4.1. User-Initiated Calls 

   The extensions in this document can also be applied in user-initiated 
   calls, although the example described in this document is about 
   network-initiated Call. Note that, in this case, the first node 
   within the first network domain may be responsible for specifying the 

 
Zhang                 Expires September 01, 2009               [Page 8] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Call Path explicitly in the Notify message. The procedures should 
   comply with the description in the Section 7.2 of [RFC 4974]. 

5. Security Considerations 

   The security considerations about Call setup in single domain are 
   described in [RFC 4974]. In the case of multi-domain environment, the 
   security about Call is similar to that of Connection which is 
   described in [RFC 5151]. Therefore, please refer to the corresponding 
   Security Consideration sections in [RFC 4974] and [RFC 5151] to take 
   into account the security issues. 

6. Manageability Considerations 

   The mechanisms defined in this document call upon the use of policy 
   at Call Managers. Such policy SHOULD be available for configuration 
   by the operator either directly acting on the Call Manager or through 
   a policy server. Important information for the application of policy 
   is carried in the Call establishment messages (Notify messages) in 
   the Session, Session_Attributes, Sender_Template, Link_Capability, 
   and Policy_Data objects. 

   The mechanism used to determine the entire Call Path or next Call 
   Manager in a Call Path is beyond the scope of this document. One 
   solution is to allow configuration of the Call Path from the operator 
   as part of the service request (just as the explicit path of a label 
   switched path (LSP) can be specified by the operator). 

   Operators will expect to be able to inspect Call Managers and 
   determine for which Calls they are initiator, transit, or terminator. 
   Furthermore, they will expect to be able to inspect a Call at any 
   Call Manager that it uses, and determine all information about the 
   Call including its Call Path. 

7. IANA Considerations 

   This document introduces two new classes named Call_ERO and Call_RRO. 

7.1. Call_ERO Object  

   Class-Num = TBD (0bbbbbbb) 

   C-Type=1 (Call_ERO) 

   The Call_ERO object is only used for Call messages in Notify messages. 

   Subobjects of the Call_ERO object with C-Type 1: 

 
Zhang                 Expires September 01, 2009               [Page 9] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

             1       IPv4 prefix 

             2       IPv6 prefix 

            32       Autonomous system number 

7.2. Call_RRO Object  

   Class-Num = TBD (11bbbbbb) 

   C-Type=1 (Call_RRO) 

   The Call_RRO object is only used for Call messages in Notify messages. 

   The subobjects of Call_RRO are defined in Section 3 of this document. 

7.3. RSVP Error Codes and Error Values 

   The Call message (Notify message) should be rejected when any Call 
   Manager which receives the Call message including Call_ERO does not 
   recognize the Call_ERO. 

      o  Error Codes: 

         - Call Management (value 32) 

      o  Error Values: 

         - Call Management/Unknown Call_ERO      (value=TBD) 

8. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC4974] D. Papadimitriou, A. Farrel, "Generalized MPLS (GMPLS) 
             RSVP-TE Signaling Extensions in Support of Calls ", RFC 
             4974, August 2007. 

            [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T.,                    
             Srinivasan, V.  and G. Swallow, "RSVP-TE: Extensions               
             to RSVP for LSP Tunnels", RFC 3209, December 2001. 

 

Zhang                 Expires September 01, 2009              [Page 10] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 
             (GMPLS) Signaling Functional Description", RFC 3471, 
             January 2003. 

   [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 
             Switching (GMPLS) Signaling Resource ReserVation Protocol-
             Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 
             January 2003. 

   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 
             "Generalized Multiprotocol Label Switching (GMPLS) User- 
             Network Interface (UNI): Resource ReserVation Protocol- 
             Traffic Engineering (RSVP-TE) Support for the Overlay 
             Model", RFC 4208, October 2005. 

   [RFC5151] A. Farrel, A. Ayyangar, JP. Vasseur, "Inter-Domain MPLS and 
             GMPLS Traffic Engineering-Resource Reservation Protocol-
             Traffic Engineering (RSVP-TE) Extensions", RFC 5151, 
             February 2008. 

   [RBNF]    Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used 
             in Various Protocol  Specifications", draft-farrel-rtg-
             common-bnf, work in progress. 

 

Zhang                 Expires September 01, 2009              [Page 11] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

9. Authors' Addresses

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: zhangfatai <at> huawei.com

   Dan Li
   Huawei Technologies Co., Ltd.
   F3-5-B R&D Center, Huawei Base,
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973237
   Email: danli <at> huawei.com

   Jianhua Gao
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28972912
   Email: gjhhit <at> huawei.com

Acknowledgment 

   TBD. 

Intellectual Property 

   The IETF Trust takes no position regarding the validity or scope of   
   any Intellectual Property Rights or other rights that might be   
   claimed to pertain to the implementation or use of the technology   
   described in any IETF Document or the extent to which any license   
   under such rights might or might not be available; nor does it   
   represent that it has made any independent effort to identify any   
   such rights. 

 

Zhang                 Expires September 01, 2009              [Page 12] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

   Copies of Intellectual Property disclosures made to the IETF   
   Secretariat and any assurances of licenses to be made available, or   
   the result of an attempt made to obtain a general license or   
   permission for the use of such proprietary rights by implementers or   
   users of this specification can be obtained from the IETF on-line IPR   
   repository at http://www.ietf.org/ipr 

   The IETF invites any interested party to bring to its attention any   
   copyrights, patents or patent applications, or other proprietary   
   rights that may cover technology that may be required to implement   
   any standard or specification contained in an IETF Document. Please   
   address the information to the IETF at ietf-ipr <at> ietf.org. 

   The definitive version of an IETF Document is that published by, or   
   under the auspices of, the IETF. Versions of IETF Documents that are   
   published by third parties, including those that are translated into   
   other languages, should not be considered to be definitive versions   
   of IETF Documents. The definitive version of these Legal Provisions   
   is that published by, or under the auspices of, the IETF. Versions of   
   these Legal Provisions that are published by third parties, including   
   those that are translated into other languages, should not be   
   considered to be definitive versions of these Legal Provisions. 

   For the avoidance of doubt, each Contributor to the IETF Standards   
   Process licenses each Contribution that he or she makes as part of   
   the IETF Standards Process to the IETF Trust pursuant to the   
   provisions of RFC 5378. No language to the contrary, or terms,   
   conditions or rights that differ from or are inconsistent with the   
   rights and licenses granted under RFC 5378, shall have any effect and   
   shall be null and void, whether published or posted by such   
   Contributor, or included with or in such Contribution. 

 
Disclaimer of Validity 

   All IETF Documents and the information contained therein are provided   
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE   
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE   
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL   
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY   
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE   
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS   
   FOR A PARTICULAR PURPOSE. 

 
Full Copyright Statement 

 

Zhang                 Expires September 01, 2009              [Page 13] 

Internet-Draft    RSVP-TE extensions to GMPLS Calls          March 2009 

 
   Copyright (c) 2009 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 in effect on the date of   
   publication of this document (http://trustee.ietf.org/license-info).   
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 

 

Zhang                 Expires September 01, 2009              [Page 14] 

Internet-Drafts | 3 Mar 2009 17:45
Picon
Favicon

I-D Action:draft-ietf-ccamp-rwa-info-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-info-02.txt
	Pages           : 17
	Date            : 2009-03-03

This document provides a model of information needed by the routing 
and wavelength assignment (RWA) process in wavelength switched 
optical networks (WSONs).  The purpose of the information described 
in this model is to facilitate constrained lightpath computation in 
WSONs, particularly in cases where there are no or a limited number 
of wavelength converters available. This model does not include 
optical impairments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-ccamp-rwa-info-02.txt): message/external-body, 70 bytes
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts | 3 Mar 2009 19:30
Picon
Favicon

I-D Action:draft-ietf-ccamp-rwa-wson-encode-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-encode-01.txt
	Pages           : 30
	Date            : 2009-03-03

A wavelength switched optical network (WSON) requires that certain 
key information elements are made available to facilitate path 
computation and the establishment of label switching paths (LSPs). 
The information model described in "Routing and Wavelength Assignment 
Information for Wavelength Switched Optical Networks" shows what 
information is required at specific points in the WSON. 

The information may be used in Generalized Multiprotocol Label 
Switching (GMPLS) signaling protocols, and may be distributed by 
GMPLS routing protocols. Other distribution mechanisms (for example, 
XML-based protocols) may also be used. 

This document provides efficient, protocol-agnostic encodings for the 
information elements necessary to operate a WSON. It is intended that 
protocol-specific documents will reference this memo to describe how 
information is carried for specific uses. 

Conventions used in this document 

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

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-encode-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Shoichiro Seno | 4 Mar 2009 10:27
Picon

New I-D: draft-seno-ccamp-wson-impairment-compensate-cntl-00

Hi CCAMPers, and especially those interested in WSON;

I have submitted a new draft for your consideration: 
draft-seno-ccamp-wson-impairment-compensate-cntl-00.txt.
http://www.ietf.org/internet-drafts/draft-seno-ccamp-wson-impairment-compensate-cntl-00.txt

Please take a look at this I-D, of which abstract is shown below. 
Any comments are welcome.

============================================================== 
Abstract:
This memo describes requirements of compensation control of optical 
impairments such as chromatic dispersion for dynamic optical paths, 
as well as automatic discovery of fiber-related impairments over 
links by collaboration of a pair of adjacent nodes upon installation. 
It is intended as a supplement to the wavelength switched optical 
networks (WSON) framework with impairments, because GMPLS-based 
automatic adjustment of impairment compensation and automatic 
discovery of link impairments will improve usability of WSON.
==============================================================

Thank you for your attention.

Sho
--
        Shoichiro Seno (E-mail) Senoo.Shoichiro <at> dc.MitsubishiElectric.co.jp
        Information Technology R&D Center, Mitsubishi Electric Corporation

Internet-Drafts | 4 Mar 2009 18:15
Picon
Favicon

I-D Action:draft-ietf-ccamp-rwa-wson-framework-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)
	Author(s)       : G. Bernstein
	Filename        : draft-ietf-ccamp-rwa-wson-framework-02.txt
	Pages           : 48
	Date            : 2009-03-04

This memo provides a framework for applying Generalized Multi-
Protocol Label Switching (GMPLS) and the Path Computation Element 
(PCE) architecture to the control of wavelength switched optical 
networks (WSON).  In particular we provide control plane models for 
key wavelength switched optical network subsystems and processes. The 
subsystems include wavelength division multiplexed links, tunable 
laser transmitters, reconfigurable optical add/drop multiplexers 
(ROADM) and wavelength converters.  

Lightpath provisioning, in general, requires the routing and 
wavelength assignment (RWA) process. This process is reviewed and the 
information requirements, both static and dynamic for this process 
are presented, along with alternative implementation scenarios that 
could be realized via GMPLS/PCE and/or extended GMPLS/PCE protocols. 
This memo does NOT address optical impairments in any depth and 
focuses on topological elements and path selection constraints that 
are common across different WSON environments.  It is expected that a 
variety of different techniques will be applied to optical 
impairments depending on the type of WSON, such as access, metro or 
long haul.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-wson-framework-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Fabien Verhaeghe | 5 Mar 2009 08:52
Favicon

OSPF inter-AS extensions for GMPLS (RFC5392) questions


Hello,

Sorry to come a little late on this but I have a question on inter-AS
extensions RFC5392 (also applicable on ISIS extensions).
In section 4:
" Only some essential TE information for the link needs to be
   advertised; i.e., the Link Type, the Remote AS number, and the Remote
   ASBR ID."

First what does "remote" mean here? is it remote in the context of the
proxied link or in the context of the Router?
i.e.

RouterA in AS1 ------TE Link------ RouterB in AS2

I guess it is in the context of the link. That is in LSA generated by router
A for B->A link (proxied) we put AS1 and routerA ASBR Id. Is that correct?

Second question: I'm not sure about the purpose of "only some essential TE
information for the link needs to be advertised" sentence.
Does it mean it not allowed to put other information like bandwidth,
protection type? (in case the link has asymetric characteristic)
Besides I think another essential information is the remote link Id or
remote IP address in order to correlate the proxied B->A link with the A->B
link.
Do you agree?

Thanks
Fabien

-----------------------------------

Fabien Verhaeghe (Senior consultant)
Marben Products


Gmane