Network Working Group P. Tsuchiya INTERNET-DRAFT Bellcore November 1992 Pip Objects Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract Pip has a strong separation of packet syntax and semantics. Each Pip system determines its own syntax for the Handling Directive (HD) and Routing Context (RC) fields. While the syntax can be local, the semantics that the syntax represents must be globally unambiguous. This document 1) describes the syntax for globally unambiguous Pip HD and RC semantics, 2) a packet format for exchanging the mappings between semantics and HD and RC syntax, and 3) lists objects defined for Pip operation. Acknowledgements Pip WG, Expires May. 1, 1993 [Page 1] INTERNET-DRAFT Pip Objects November 1992 1. Introduction Pip has a strong separation of packet syntax and semantics. Each Pip system determines its own syntax for the Handling Directive (HD) and Routing Context (RC) fields. While the syntax can be local, the semantics that the syntax represents must be globally unambiguous. There are many different kinds of semantics that can be encoded in the HD or RC. Examples of such semantics are "low cost route", "low delay queueing", "route along first alternate path", and "multicast address". When one Pip system transmits a Pip packet to another Pip system, it must translate the HD and RC from its own syntax to that of the receiving Pip system. To do this, the Pip system must know how the receiving system is interpreting the HD and RC. The common means of knowing this is to exchange configuration information. To do this, there must be a means of unambiguously conveying semantic meaning between Pip systems. This document defines how semantic meaning is conveyed by Pip systems. This document is also the repository for better-known Pip semantics. 2. Pip Objects The Pip Object is the basic unit for identifying a Pip semantic mean- ing. Pip Objects have names and descriptors (Pip Object Names, PON, and Pip Object Descriptors, POD). A PON is a globally unique number 8 octets in length. A POD is a string of characters of any length. PODs need not be globally unique. The first octet of the PON is the PON Type. If the first octet is value 1, then the next 4 octets are an IP address, followed by a 3 octet Pip Object number. If the first octet is value 2, then the next 6 octets is an IEEE 802 address followed by a 1 octet Pip Object number. The purpose of the IP or IEEE 802 address is to define an authority for the subsequent Pip Object number for the purposes of insuring that every Pip Object has a unique PON. This allows virtually any- body to create and name a Pip Object. Note that PONs have no rela- tion what-so-ever to the IP or IEEE 802 address they contain. Pip WG, Expires May. 1, 1993 [Page 2] INTERNET-DRAFT Pip Objects November 1992 Pip Objects can be hierarchically classed. If multiple Pip objects are in a single class, then an HD or RC can only indicate one member of the class. For instance, "address family" is a Pip Object class. An RC can only denote one address family. A class of Pip Objects is itself a Pip Object (a meta Pip Object) in that the class itself is denoted by a PON and POD. Pip Objects can be dependent on other Pip Objects. That is, the interpretation of one Pip Object depends on the value of another Pip Object. For instance, "hierarchical level" can be dependent on "address family" in that a given RC value for hierarchical level can be one level for one address family and another level for another address family. 3. Assigned Pip Objects The following is a list of assigned Pip Objects. This is not meant to be a complete list, and other documents (such as RFC 1060) may list well-known Pip Objects. The PONs are written as x.x.x.x.x.x.x.x, where each x is a hex number representing one octet. The characters of the PODs are delimited by double quotes ("). The Range gives the range of values that the Pip Object can have. (A range of 0 means that the Pip Object either is active or is not active in the HD or RC, but otherwise does not have values per se.) The "Member of:" denotes which class (meta Pip Object), if any, the Pip Object belongs to. The "Dependency:" denotes which other Pip Objects, if any, the Pip Object is dependent on for its context. PON = 2.8.0.20.f.d4.2c.1 POD = "Pip Address Family" Range = 0 on up Member of: none Dependency: none This is a meta Pip Object that denotes which address family the FTIF comes from. PON = 2.8.0.20.f.d4.2c.2 POD = "Single-level Multicast Address" Range = 0 Pip WG, Expires May. 1, 1993 [Page 3] INTERNET-DRAFT Pip Objects November 1992 Member of: "Pip Address Family" (2.8.0.20.f.d4.2c.1) Dependency: none This Pip Object indicates that the current FTIF should be inter- preted as being a single-level multicast address. Examples of single-level multicast addresses are those from the Class D IP address space and those used by the CBT multicast algorithm. Note that the corresponding FTIF value does not have to be globally agreed upon by all participants of the multicast tree. It can be remapped from router to router. Therefore, there is no need for a global number authority for this address space. PON = 2.8.0.20.f.d4.2c.3 POD = "Pip Address Level" Range = 0 on up Member of: none Dependency: "Pip Address Family" (2.8.0.20.f.d4.2c.1) This Pip Object denotes which level of a hierarchical address is being operated on. It is dependent on the type of address (Pip Address Family) that is active. PON = 2.8.0.20.f.d4.2c.4 POD = "IP-style Precedence" Range = 0 - 7 Member of: none Dependency: none This Pip Object has the same semantics as bits 0 through 2 of the IP Type of Service field. PON = 2.8.0.20.f.d4.2c.5 POD = "IP-style Type of Service" Range = 0 - 4 Member of: none Dependency: none This Pip Object has the same semantics as bits 3 through 6 of the IP Type of Service field. The values of this Pip Object are interpreted as follows: PO Value Equivalent IP TOS -------- ----------------- 0 0000 (normal service) 1 0001 (minimize monetary cost) 2 0010 (maximize reliability) 3 0100 (maximize throughput) Pip WG, Expires May. 1, 1993 [Page 4] INTERNET-DRAFT Pip Objects November 1992 4 1000 (minimize delay) PON = 2.8.0.20.f.d4.2c.6 POD = "IANA-rooted Hierarchical Address" Range = 0 Member of: "Pip Address Family" (2.8.0.20.f.d4.2c.1) Dependency: none This Pip Object indicates that the current FTIF should be inter- preted as coming from the hierarchical unicast address space assigned by the IANA (the Internet Assigned Numbers Authority). (That is, the top-level assignments come from the IANA.) When this address is in use, the Pip Address Levels (2.8.0.20.f.d4.2c.3) are interpreted as follows. Value 0 represents the top hierarchy level (those assigned by IANA itself). Value 1 represents the next level down, and so on. PON = 2.8.0.20.f.d4.2c.7 POD = "Default Route" Range = 0 Member of: none Dependency: none This Pip Object indicates that the current FTIF should be inter- preted as choosing a default route; either an exit router or an exit backbone. PON = 2.8.0.20.f.d4.2c.8 POD = "OSI Congestion Experienced Bit" Range = 0 - 1 Member of: none Dependency: none This Pip Object is treated exactly as its OSI counterpart as defined in ISO 8473. The value 0 means no congestion experienced, and the value 1 means congestion experienced. It applies only to the HD. Pip WG, Expires May. 1, 1993 [Page 5] INTERNET-DRAFT Pip Objects November 1992 4. Packet Format for Mapping Pip Objects to HD/RC Values There are various ways that two Pip systems may exchange HD/RC syn- tax, depending on how two Pip systems configure with each other. For instance, two OSPF neighbor routers can use messages exchanged during the OSPF configuration phase to exchange HD/RC syntax. Or, Router Discovery can be used as an opportunity to convey HD/RC syntax. In this section, a standard packet format is described that can be used in any number of other protocols. This document does not define a protocol for neighbor configuration per se--only a packet format that can be used with other neighbor configuration algorithms. The object mapping format structure is shown in Figure 1. length, in bits +===========================+ | Version | 8 +---------------------------+ | Object_Map_Size | 8 +---------------------------+ | Number_of_HD_Maps | 8 +---------------------------+ | Number_of_RC_Maps | 8 +===========================+ | Reserved | 24 +---------------------------+ | Packet_SubID | 8 +===========================+ | 1st Individual Object Map | variable +===========================+ | 2nd Individual Object Map | variable +===========================+ . . . +===========================+ | Nth Individual Object Map | variable +===========================+ Figure 1: Object Map Format The Version field is 0 for the format defined in this document. Pip WG, Expires May. 1, 1993 [Page 6] INTERNET-DRAFT Pip Objects November 1992 The Object_Map_Size gives the length of the entire Object Map in 32- bit words, not including the first word. The Individual Object Maps are ordered by those that apply to the HD, followed by those that apply to the RC. If an object applies to both HD and RC, it will appear twice. Among each group (HD or RC) of Individual Object Maps, the Individual Object Maps must appear in order of numerically lowest Target_Pip_Ob- ject_Name first to numerically highest Target_Pip_Object_Name last. The Number_of_HD_Maps tells how many Individual Object Maps apply to the HD. The Number_of_RC_Maps tells how many Individual Object Maps apply to the RC. The Packet_SubID field gives the value for the the Packet SubID field of the Pip header when this Pip Object Map is used. Each Object Map has the format shown in Figure 2. The Least_Significant_Bit and Most_Significant_Bit fields indicate which (contiguous) bits of the HD/RC this Object Map apply to. These bits are referred to as the HD/RC Subfield. The NULL_Value field tells which value of the HD/RC Subfield represents the absence of the Pip Object. This value is necessary in the case where the HD/RC in the Pip packet does not contain the Pip Object at all. The NULL_Value field is set to hex ff if there is no NULL value (in other words, some valid value of the Pip Object is present in all packets). The Number_of_Listed_Objects field indicates how many Pip_Ob- ject_Names are in this Individual Pip Object Map. If the Number- _of_Listed_Objects field is 0, then the Individual Pip Object Map is defined in terms of matching a range of HD/RC Subfield values to a range of Pip Object values. If the Number_of_Listed_Objects field is not 0, then the Individual Pip Object Map is defined in terms of matching a range of HD/RC Subfield values to a list of Pip Objects. (Examples of Individual Pip Object Maps are given at the end of this document.) The HD/RC_From_Value and the HD/RC_To_Value fields describe a range of values in the HD/RC Subfield. This range must not include the Pip WG, Expires May. 1, 1993 [Page 7] INTERNET-DRAFT Pip Objects November 1992 NULL_Value (in other words, the NULL_Value must be either hex ff, or it must come before or after the range). The HD/RC_From_Value must be smaller than or equal to the HD/RC_To_Value. If a range of Pip Object values is to be mapped into the range of HD/RC Subfield values, then the PO_From_Value and PO_To_Value give the range of Pip Object values. In this case, the Number_of_Listed- _Objects field will be 0, and no Pip_Object_Name fields will be listed. If a list of Pip Objects is to be mapped into the range of HD/RC Sub- field values, then the Number_of_Listed_Objects field will be non-0. In this case, the combined PO_From_Value and PO_To_Value fields are treated as a single 16-bit field that indicates the total length of the individual Object Map, in 32-bit words. This allows the next individual Object Map to be located easily, particularly in the case where (variable length) Pip Object Descriptors are included. The value in the Number_of_Listed_Objects must equal the HD/RC_To_Value minus the HD/RC_From_Value. In other words, for every value in the range of HD/RC Subfield values, there must be a Pip Object to match it. The Target_Pip_Object_Name gives the Pip Object that the Individual Pip Object Map applies to. The Target_Pip_Object_Desc gives the description of the Pip Object that the Individual Pip Object Map applies to. The format of this and subsequent Pip_Object_Descs is given below. Following this is a list of Pip_Object_Name fields. The number of Pip_Object_Name fields is equal to the value in the Number_of_Listed- _Objects field. The first Pip_Object_Name applies to the first value in the HD/RC Subfield range, the second Pip_Object_Name applies to the second value in the HD/RC Subfield range, and so on. Following this is a list of Pip_Object_Desc fields. The existence of these fields is optional (it may not be necessary to give the charac- ter string describing the Pip Object). However, if any Pip_Ob- ject_Descs are included, then all must be included (that is, there must be a Pip_Object_Desc for every Pip_Object_Name. However, the Pip_Object_Desc can be NULL--that is, omit the character string). The Pip_Object_Descs correspond to the listed Pip_Object_Names. Each Pip_Object_Desc (including the Target_Pip_Object_Desc) has the following format: The first 8 bits indicates the character set type, Pip WG, Expires May. 1, 1993 [Page 8] INTERNET-DRAFT Pip Objects November 1992 length, in bits +===========================+ | Least_Significant_Bit | 8 +---------------------------+ | Most_Significant_Bit | 8 +---------------------------+ | NULL_Value | 8 +---------------------------+ | Number_of_Listed_Objects | 8 +===========================+ | HD/RC_From_Value | 8 +---------------------------+ | HD/RC_To_Value | 8 +---------------------------+ | PO_From_Value | 8 +---------------------------+ | PO_To_Value | 8 +===========================+ | Target_Pip_Object_Name | 64 +===========================+ | Target_Pip_Object_Desc | var (optional) +===========================+ | 1st Pip_Object_Name | 64 (optional) +===========================+ | 2nd Pip_Object_Name | 64 (optional) +===========================+ . . . +===========================+ | Nth Pip_Object_Name | 64 (optional) +===========================+ | 1st Pip_Object_Desc | var (optional) +===========================+ | 2nd Pip_Object_Desc | var (optional) +===========================+ . . . +===========================+ | Nth Pip_Object_Desc | var (optional) +===========================+ Figure 2: Individual Object Map Format Pip WG, Expires May. 1, 1993 [Page 9] according to the following table: INTERNET-DRAFT Pip Objects November 1992 Value Character Set Type Character Size ------ ------------------ -------------- 0 Reserved 1 ASCII 8 bits 2-255 Reserved The second 8 bits gives the number of characters. This field can be 0. Following this are the characters. Each individual character must take up either an 8-bit field, a 16-bit field, or a 32-bit field. If the character sizes are 32 bits, then each character must fall on a 32-bit boundary. Each Pip_Object_Desc is padded out to a 32-bit boundary. The padding is sent as 0 and ignored upon receipt. 5. Pip Object Map Example In this example, Pip system A is conveying to Pip system B its under- stood Pip objects and its local mapping. System A uses the following objects in its Handling Directive: 1. OSI Congestion Experienced Bit (2.8.0.20.f.d4.2c.8) 2. IP-style Type of Service (2.8.0.20.f.d4.2c.5) System A wishes to use bits 0 and 1 of the Handling Directive (the least significant bits) for the congestion bit, and bits 2 through 4 as the TOS bits. System A uses the following Pip Objects in its Routing Context: 1. Pip Address Family (2.8.0.20.f.d4.2c.1) 2. Single-level Multicast Address (2.8.0.20.f.d4.2c.2) 3. Pip Address Level (2.8.0.20.f.d4.2c.3) 4. IANA-rooted Hierarchical Address (2.8.0.20.f.d4.2c.6) This represents a case where system A is not using TOS routing (but is using TOS for handling purposes). System A can handle two types Pip WG, Expires May. 1, 1993 [Page 10] INTERNET-DRAFT Pip Objects November 1992 of addresses, hierarchical addresses and multicast addresses. The Pip Address Family object is needed to couple the two address types in the same RC Subfield. The Pip Address Level object is for use with the hierarchical address. System A uses bit 0 to indicate the address type, and bit 1 to indi- cate the level (assume that System A only routes on two levels of the hierarchy). System A would send the following Pip Object Map to System B: Part Field Contents ---- ----- -------- First word Version 0 Object_Map_Size X Number_of_HD_Maps 2 Number_of_RC_Maps 2 1st Individual Object Map Least_Significant_Bit 0 Most_Significant_Bit 1 NULL_Value 0 Number_of_Listed_Objects 0 HD/RC_From_Value 1 HD/RC_To_Value 2 PO_From_Value 0 PO_To_Value 1 Target_Pip_Object_Name 2.8.0.20.f.d4.2c.8 Target_Pip_Object_Desc "OSI Congestion Experienced Bit" 2nd Individual Object Map Least_Significant_Bit 2 Most_Significant_Bit 4 NULL_Value ff Number_of_Listed_Objects 0 HD/RC_From_Value 0 HD/RC_To_Value 4 PO_From_Value 0 PO_To_Value 4 Target_Pip_Object_Name 2.8.0.20.f.d4.2c.5 Pip WG, Expires May. 1, 1993 [Page 11] INTERNET-DRAFT Pip Objects November 1992 Target_Pip_Object_Desc "IP-style Type of Service" 3rd Individual Object Map Least_Significant_Bit 0 Most_Significant_Bit 0 NULL_Value ff Number_of_Listed_Objects 2 HD/RC_From_Value 0 HD/RC_To_Value 1 PO_From_Value -- PO_To_Value X Target_Pip_Object_Name 2.8.0.20.f.d4.2c.1 Target_Pip_Object_Desc "Pip Address Family" 1st Pip_Object_Name 2.8.0.20.f.d4.2c.6 2nd Pip_Object_Name 2.8.0.20.f.d4.2c.2 1st Pip_Object_Desc "IANA-rooted Hierarchical Address" 2nd Pip_Object_Desc "Single-level Multicast Address" 4th Individual Object Map Least_Significant_Bit 1 Most_Significant_Bit 1 NULL_Value ff Number_of_Listed_Objects 0 HD/RC_From_Value 0 HD/RC_To_Value 1 PO_From_Value 3 PO_To_Value 4 Target_Pip_Object_Name 2.8.0.20.f.d4.2c.3 Target_Pip_Object_Desc "Pip Address Level" Following is an explanation of the above Pip Object Map. The first word indicates that there are two HD Individual Object Maps and two RC Individual Object Maps. The 1st Individual Object Map contains the OSI Congestion Experienced Bit. It is understood that this Individual Object Map applies to the HD, since the two HD Individual Objects Maps are listed first. Since this object requires two bits, and since those bits are in the 0 and Pip WG, Expires May. 1, 1993 [Page 12] INTERNET-DRAFT Pip Objects November 1992 1 bit position of the HD, the Least_Significant_Bit field is set to 0 and the Most_Significant_Bit field is set to 1. In this example, two bits are used to convey the Congestion Experi- enced Bit, to account for the NULL encoding. The implication of the NULL encoding would be that the packet passed through a system that did not implement the Congestion Experienced Bit, and therefore any previous setting was lost. (In practice, it would almost certainly be unnecessary to have a NULL encoding for this bit. Even if a sys- tem does not recognize a Pip Object, it could be made to pass the object untouched in the event that a previous system and a subsequent system (not necessarily neighbors) recognize the object.) The OSI Congestion Experienced Bit Pip Object defines values 0 and 1 as valid settings for the bit. But, System A has chosen the value 0 as its local syntax for NULL. Therefore, System A is mapping the local syntax values 1 - 2 (HD/RC_From_Value and HD/RC_To_Value) into the Pip Objects values 0 - 1 (PO_From_Value and PO_To_Value). In other words, if System A receives the value 2 in bits 0 and 1 of the HD field, it will interpret it as "congestion experienced" (Pip Object value 1). Finally the Target_Pip_Object_Name and Target_Pip_Object_Desc iden- tify the 1st Individual Object Map as being the OSI Congestion Experienced Bit. The 2nd Individual Object Map conveys the IP-style Type of Service (TOS) information. The Least_Significant_Bit and Most_Signifi- cant_Bit field values of 2 and 4 indicate that bits 2 and 4 of the HD carry the TOS information. The NULL_Value field value of ff indicates that there is no NULL value for this Pip Object. This is because the "normal service" value can be considered the default value in the case where the information has been lost. (Note again that in practice it should not be necessary to lose HD or RC information since systems that don't recognize certain Pip Objects can still pass them on untouched.) Since there is no NULL value, the Pip Object values for TOS (0 through 4) can be mapped directly into the HD values 0 through 4. Thus, the HD/RC_From_Value and PO_From_Value fields are set to 0, and the HD/RC_To_Value and PO_To_Value fields are set to 4. Note that it is not possible for a Pip System to convey that it wants to recognize certain TOS values (say, minimize monetary cost = 1 and minimize Pip WG, Expires May. 1, 1993 [Page 13] INTERNET-DRAFT Pip Objects November 1992 delay = 4) and not others. The only mechanism in the Pip Object Map for conveying a list of selected values is through the list of Pip_Object_Names. But, the IP-style Type of Service Pip Object is specified as a range of values, not as a list of Pip Objects (although it could have been). The 3rd Individual Object Map specifies the address family being used. Because members of the address family are specified as Pip Objects, this Individual Object Map uses a list of Pip_Object_Names (as indicated by the non-zero Number_of_Listed_Objects field). The "--" and "X" under PO_From_Value and PO_To_Value here indicate that the combined two fields are being used to indicate the length of the 3rd Individual Object Map. (For this example, it is not neces- sary to calculate the actual length.) This Individual Object Map lists two Pip_Object_Names (not including the Target_Pip_Object_Name). Likewise, the range of the HD/RC Sub- field is 2 (values 0 and 1). Thus, a value of 0 in bit 0 of the RC means that an IANA-rooted Hierarchical Address (listed first) is in the FTIF Chain, and a value of 1 in bit 0 means that a Single-level Multicast Address (listed second) is being used. Finally, the 4th Individual Object Map gives the hierarchical level of the address when the IANA-rooted Hierarchical Address is being used. As specified in the IANA-rooted Hierarchical Address Pip Object description, the Pip Object value 0 represents the top level, value 1 the next level down, and so on. In this particular example, System A only routes at levels 3 and 4 (it is an intra-domain router, and tunneling is used to route packets externally). Thus, it only needs one bit to convey the level. An HD/RC Subfield value of 0 (HD/RC_From_Value = 0) indicates level 3 (PO_From_Value = 3), and an HD/RC Subfield value of 1 (HD/RC_From_Value = 1) indicates level 4 (PO_From_Value = 4). Pip WG, Expires May. 1, 1993 [Page 14]