Skip to main content

Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)
RFC 4258

Revision differences

Document history

Date Rev. By Action
2018-12-20
05 (System)
Received changes through RFC Editor sync (changed abstract to 'The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching …
Received changes through RFC Editor sync (changed abstract to 'The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs).

This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. This memo provides information for the Internet community.')
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Bill Fenner
2005-11-22
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-11-22
05 Amy Vezza [Note]: 'RFC 4258' added by Amy Vezza
2005-11-16
05 (System) RFC published
2005-03-30
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-03-23
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-03-23
05 Amy Vezza IESG has approved the document
2005-03-23
05 Amy Vezza Closed "Approve" ballot
2005-02-09
05 Alex Zinin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Alex Zinin
2005-01-28
05 Alex Zinin checking with WG chairs if we can respin this doc with a NULL IANA section
2004-12-15
05 Bill Fenner [Ballot Position Update] Position for Bill Fenner has been changed to No Objection from Discuss by Bill Fenner
2004-10-29
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-10-29
05 (System) Removed from agenda for telechat - 2004-10-28
2004-10-28
05 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2004-10-28
05 Bill Fenner [Ballot discuss]
Placeholder for liaison issues
2004-10-28
05 Bill Fenner [Ballot Position Update] New position, Discuss, has been recorded for Bill Fenner by Bill Fenner
2004-10-28
05 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2004-10-28
05 Michelle Cotton IANA Comments:
Section 4.5.3 and 4.5.4 have some defined values.  Does IANA need to do anything
with these?
2004-10-28
05 Harald Alvestrand [Ballot comment]
Reviewed by Michael Patton, Gen-ART

Review entered as comment on document.
A number of typos that may warrant another spin, but not blocking.
2004-10-28
05 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-10-28
05 Harald Alvestrand
Review by Michael Patton, Gen-ART

Summary: This draft is ready for publication as an Informational RFC

I managed to comprehend the whole document, in isolation.  …
Review by Michael Patton, Gen-ART

Summary: This draft is ready for publication as an Informational RFC

I managed to comprehend the whole document, in isolation.  But,
without an understanding of the several ITU references, none of which
I've read, I can't comment on whether it is really a good set of
requirement definitions.



General comment:  There's a bit of cognitive disonance in the
terminology because of the meshing of circuit switching and packet
switching in the descriptions.  I don't think this is enough to slow
the document.  If the document does go through another round, I might
be persuaded to catalog some of them.  However, once I realized that I
needed to do a TPC to TCP mapping of terminology, it all became clear.


In sections 4.5.1 and 4.5.4 the term SRLG appears, but is never
expanded or explained.  While it may be explained in one of the
references, at least expanding it at first use would be nice.  Neither
of the references is important enough to make this a restrictive
problem, but it would be nice to have an expansion.


typos
-----

Section 3 "provides among other capabilities support"
      => "provides, among other capabilities, support"

bottom of pages 5 and 13 have orphaned section headings.

Section 4.2 "SHOULD not" => "SHOULD NOT"

Section 4.2 the last sentence of paragraph 3 ("This MAY be achieved
  using a number of mechanisms.") doesn't really say anything.  It's
  the way you lead into a list of the said mechanisms, but there
  isn't a list, so that construct is meaningless.  I think what they
  meant was "This specification does not restrict the mechanisms by
  which this may be achieved."

Section 4.5.4 under "Connection Types" shouldn't the abbreviation for
  "Termination Connection Point" be TCP (a confusing one, I must
  admit, but not as confusing as having them both be the same)?  It
  certinly seems to be referenced this way at other points in the
  document.  And later that assumption is verified by the Terminology
  section.



One typo seems to be systematic, the word "bounded" is used where
"bound" is obviously meant.  Interestingly enough there are a few
places where the words are used correctly.  These are the erroneous
uses that I found:

Section 4 "at each RC bounded to the same RA"
      => "at each RC bound to the same RA"

Section 4.2 "RC(s) bounded to a RA" => "RC(s) bound to a RA"

Section 4.5.2 "the advertisement is bounded"
  => "the advertisement is bound"

Section 6 "RCs bounded to different" => "RCs bound to different"

and the related one:

Section 6 "when multiple RCs bound to a single RA"
should either be
"when multiple RCs are bound to a single RA"
or"when multiple RCs bind to a single RA"
I think the first of those two is more correct.
2004-10-27
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-10-27
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-10-26
05 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2004-10-26
05 Steven Bellovin [Ballot comment]
Should the security considerations section reference the rpsec work?
2004-10-26
05 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin
2004-10-25
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-10-25
05 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-10-25
05 Scott Hollenbeck [Ballot comment]
Missing IANA Considerations.
2004-10-25
05 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-10-21
05 Alex Zinin State Changes to IESG Evaluation from AD Evaluation::AD Followup by Alex Zinin
2004-10-21
05 Alex Zinin Placed on agenda for telechat - 2004-10-28 by Alex Zinin
2004-10-21
05 Alex Zinin [Ballot Position Update] New position, Yes, has been recorded for Alex Zinin
2004-10-21
05 Alex Zinin Ballot has been issued by Alex Zinin
2004-10-21
05 Alex Zinin Created "Approve" ballot
2004-10-21
05 (System) Ballot writeup text was added
2004-10-21
05 (System) Last call text was added
2004-10-21
05 (System) Ballot approval text was added
2004-10-13
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-10-13
05 (System) New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
2004-06-04
05 Alex Zinin State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Alex Zinin
2004-06-04
05 Alex Zinin
AD-review comments:

The list of authors is too long according to the recent RFC Editor policies.

Same comment regarding the 2119 languages as for the …
AD-review comments:

The list of authors is too long according to the recent RFC Editor policies.

Same comment regarding the 2119 languages as for the previous document.

Comments on specific parts of the text:

> 4. ASON Routing Architecture and Requirements
...
>    The failure of a RC, or the failure of communications between RCs,
>    and the subsequent recovery from the failure condition MUST NOT
>    disrupt calls in progress and their associated connections. Calls
            ^^^^^^^^^^^^^^^^^

it took a while to realize that what's meant here wasn't calls in the process of
being established, but those already established. Some wording changes might
help here.

> 4.2 Hierarchical Routing Information Dissemination
...
>                                            If routing information is
>    exchanged between a RC, its parent, and its child RCs, it SHOULD
>    include reachability and MAY include (upon policy decision) node and
>    link topology. Communication between RAs only takes place between
>    RCs with a parent/child relationship.

the definition of "reachability" has been given at this point and the reader
wonders what it is.

>    Multiple RCs bound to the same RA MAY transform (filter, summarize,
>    etc.) and then forward information to RCs at different levels.
>    However in this case the resulting information at the receiving
>    level must be self-consistent; this MAY be achieved using a number
>    of mechanisms.

it would be useful to explain what "self-consistent" means in this
context.

>    3. Method of Communication
>
>      Two approaches exist for communication between Level N and N+1.
>
>      - The first approach places an instance of a Level N routing
>        function and an instance of a Level N+1 routing function in the
>        same system. The communications interface is within a single
>        system and is thus not an open interface subject to
>        standardization.

This is right in a sense that one doesn't have to define how to _take_ info
level N for later announcement to N+1. However, certain aspects of such
reannouncement or leaking will have to be done in a consistent manner to ensure
interoperability and basic protocol correctness (e.g., cost/metric value).

> 4.5 Routing Attributes
>
>    Routing for transport networks is performed on a per layer basis,
>    where the routing paradigms MAY differ among layers and within a
>    layer. Not all equipment supports the same set of transport layers
>    or the same degree of connection flexibility at any given layer. A
>    server layer trail may support various clients, involving different
>    adaptation functions. Additionally, equipment may support variable
>    adaptation functionality, whereby a single server layer trail
>    dynamically supports different multiplexing structures. As a result,
>    routing information MAY include layer specific, layer independent,
>    and client/server adaptation information.

The notions of "server", "layer", "server layer trail", "client", etc. haven't
been defined and are completely foreign for a usual IETF reader.

> 4.5.3 Node Attributes
>
>    All nodes belong to a RA, hence, the RA ID can be considered an
>    attribute of all nodes. Given that no distinction is made between
>    abstract nodes and those that cannot be decomposed any further, the
>    same attributes MAY be used for their advertisement. In the
>    following tables, Capability refers to the level of support required
>    in the realization of a link state routing protocol, whereas Usage
>    refers to the degree of operational and implementation flexibility.

The last sentence doesn't really help understanding what "Usage" below is used
for from the protocol design perspective. Please clarify.

>
>    The following Node Attributes are defined:
>
>        Attribute        Capability      Usage
>        -----------      -----------    ---------

> 4.5.4 Link Attributes
>
>    The following Link Attributes are defined:
>
>        Link Attribute                  Capability      Usage
>        ---------------                  -----------    ---------
>        Local SNPP link ID              REQUIRED        REQUIRED
>        Remote SNPP link ID              REQUIRED        REQUIRED
>        Layer Specific Characteristics  see Table 3
>
>                          Table 2. Link Attributes
>
>    The SNPP link ID MUST be sufficient to uniquely identify the
>    corresponding transport plane resource taking into account

Is it in conjunction with the Node ID?

> 5. Security Considerations
>
>    ASON routing protocol MUST deliver the operational security
>    objectives where required.

What are they?

> These objectives do not necessarily imply
>    requirements on the routing protocol itself, and MAY be met by other
>    established means.


Same comment about the ITU-T references as for the previous document.
2004-05-11
05 Alex Zinin Draft Added by Alex Zinin
2004-05-05
04 (System) New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt
2004-04-09
03 (System) New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt
2004-02-03
02 (System) New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
2003-12-23
01 (System) New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt
2003-12-02
00 (System) New version available: draft-ietf-ccamp-gmpls-ason-routing-reqts-00.txt