home *** CD-ROM | disk | FTP | other *** search
- Internal Ballot Version 15
-
- US BALLOT COMMENT
- Proposal to Add Multiprotocol Extensions to IDRP
-
-
- With minimal extensions to the protocol, IDRP could be used to carry route
- information for other protocols in addition to ISO 8473. This document
- outlines the necessary changes.
-
- The changes outlined allow a protocol family to be specified for reachability
- information (NLRI) and the next hop NET (NEXT_HOP attribute).
-
-
-
- Change to Text:
- ---------------
-
- 1.) Change to NLRI encoding
-
- Change the description of the NLRI encoding in section 7.3
- and any appropriate sections to:
-
- <protocol-type> <length> <prefix1-length> <prefix1>
- ... <prefixN-length> <prefixN>
-
- (Note that this definition can be repeated in the presence
- of multiple protocol families.)
-
- where: <protocol-type>
-
- A one octet field identifying the protocol family.
-
- The encoding is as follows:
-
- 00 - ISO 8473 (CLNP)
- 01(hex) - 7F (hex) reserved for assignment by ISO
- 80(hex) - FF (hex) illegal
-
- <length>
-
- A two octet field identifying the length in octets of the subsequent
- prefix information
-
- The current definitions of <prefix-length> and <prefix>
- remain the same.
-
- The above sequence may appear multiple times in the presence
- of multiple protocol families.
-
-
- 2.) Change to NEXT_HOP attribute encoding
-
-
- Replace the current encoding with the following:
-
- <protocol-type> <NET-length> <NET> <SNPA-count>
- <SNPA1-length> <SNPA1>...<SNPAn-length> <SNPAn>
-
-
- where: <protocol-type>
-
- A one octet field identifying the protocol family.
-
- The encoding is as follows:
-
- 00 - ISO 8473 (CLNP)
- 01(hex) - 7F (hex) reserved for assignment by ISO
- 80(hex) - FF (hex) illegal
-
- <NET-length>
-
- A one octet field identifying the length in octets of the subsequent NET
-
- The current definitions of <NET-length>, <NET>, <SNPA-count>,
- <SNPA-length>, and <SNPA> remain the same.
-
- The above sequence may appear multiple times in the presence of
- multiple protocol families.
-
-
- 3.) Change to ERROR PDU encoding
-
- Add new valueS in 7.4 b):
- Malformed_NLRI 11
- Attribute_Conflict 12
-
-
- Error Handling
- --------------
-
-
- 1.) Reception of an UPDATE PDU with NLRI containing a protocol type
- other than ISO 8473
-
- A BIS that receives an UPDATE PDU with NLRI containing a protocol type
- other than ISO 8473 shall ignore the NLRI information for that protocol
- type.
-
-
- 2.) Type Length Value - Length field mismatch
-
- If the length of any NLRI-Length field is inconsistent with the Length
- field of the PDU header, then the error subcode of the IDRP
- ERROR PDU shall be set to Malformed_NLRI. No further processing
- shall be done and all information in the UPDATE PDU shall be
- discarded.
-
-
- 3.) Reception of an UPDATE PDU with a NEXT_HOP attribute containing
- a protocol type other than ISO 8473
-
- A BIS that receives an UPDATE PDU with a NEXT_HOP attribute containing
- a protocol type other than ISO 8473 shall ignore the NEXT_HOP information
- for that protocol type.
-
-
- 4.) Conflicting path attributes
-
- All path attributes in an UPDATE PDU, other than the NEXT_HOP attribute,
- apply to all destinations specified by the NLRI in that UPDATE, irrespective
- of protocol family. Therefore, protocol-specific attributes may not
- appear in an UPDATE containing NLRI for multiple protocols. Specifically,
- those attributes are:
-
- SOURCE SPECIFIC QOS
- DESTINATION SPECIFIC QOS
- SOURCE SPECIFIC SECURITY
- DESTINATION SPECIFIC SECURITY
-
- A BIS that receives an UPDATE PDU containing NLRI from multiple protocol
- families and one or more of the above attributes shall send an ERROR PDU
- with a subcode of Attribute_Conflict.
-
-
- Additional Fields for PICS
- --------------------------
-
- NLRI Processing
-
- CLNP_NLPID handle CLNP NLPID in NLRI information
- status mandatory
-
-
- Implications for RD Paths and RDIs
- ----------------------------------
- Because RDIs are not qualified by protocol type, each RDI must be globally
- unambiguous across all protocols supported by IDRP. This in turn implies
- that a single RD must have congruent boundaries for all protocols.
-
-
- Aggregation of Routes from Multiple Protocol Families
- -----------------------------------------------------
- Because address information is qualified by protocol family, NLRI aggregation
- may only take place if the protocol type value is identical for all
- information being aggregated.
-
-
- Additional GDMO Field for Multiple Protocol Families
- ----------------------------------------------------
- Add definition to GDMO for a variable to indicate which
- protocol family types a BIS supports. The following
- is the suggested addition to the GDMO:
-
- In section 12.2 add to BIS GDMO:
-
- NLRIprotocoltypes GET
-
- In section 12.4 add:
-
- NLRIprotocolTypes attribute
-
- WITH ATTRIBUTE SYNTAX ISOXXXX-IDRP.BIS_group;
- Matches for Equality;
- BEHAVIOUR NLRIprotocolTypes-B
- BEHAVIOR DEFINED AS The set of protocol families
- this BIS supports in the NLRI and NEXT_HOP
- path attribute in the UPDATE BISPDU.
- REGISTERED AS {ISOXXXX-IDRP.aoi NLRIprotocolTypes(47);
-
- In section 12.8 add:
-
- NLRIprotocolTypes :== SET of protocolFamilyTypes
- protocolFamilyTypes ::= ENUMERATED {
- CLNP (0)
- }
-
-