RFC 3116
Methodology for ATM Benchmarking
Pages: 127
Informational
Informational
Part 5 of 5 – Pages 106 to 127
3.4. ATM Service: Signaling
3.4.1. CAC Denial Time and Connection Establishment Time
Objective: To determine the CAC rejection time and Connection Establishment Time on the SUT as defined in RFC 2761 "Terminology for ATM Benchmarking". Procedure: 1) Set up the SUT and test device using the bi-directional configuration. 2) Create a UNI signaling setup message, as described in Appendix C, specifying a PCR which will not allow CAC to reject the call.
3) Send the UNI signaling setup message. Note the time the setup
message was sent. Verify that the SVC has been setup with the
correct parameters. Note the time the connect message was
received
4) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will allow CAC to reject the call.
5) Send the UNI signaling setup message. Note the time the setup
message was sent. Verify that the SVC has been rejected with the
correct cause code. Note the time the release complete message
was received.
6) Compute the rejection time as the difference between the time the
release complete message was received and the time setup message
was send.
Reporting Format:
The results of the CAC Denial Time and Connection Establishment
Time tests SHOULD be reported in a form of a table. The rows
SHOULD be labeled call accepted and call rejected. The columns
SHOULD be labeled time setup sent, time response received, and
correct response. The elements of the columns 1 and 2 SHOULD be
in seconds. The elements of column 3 SHOULD be be either True or
False, indicating whether the particular condition was observed
for each test.
The table MUST also indicate the packet size in octets and traffic
rate in packets per second as generated by the test device.
3.4.2. Connection Teardown Time
Objective: To determine the Connection Teardown Time on the SUT as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Create a UNI signaling setup message, as described in Appendix C,
specifying a PCR which will not allow CAC to reject the call.
3) Send the UNI signaling setup message. Note the time the setup
message was sent. Verify that the SVC has been setup with the
correct parameters. Note the time the connect message was
received
4) Create a UNI signaling release message, as described in Appendix C, specifying a cause code of normal call clearing. 5) Send the UNI signaling release message. Note the time the release message was sent. Verify that the SVC has been terminated with the correct cause code. Note the time the release complete message was received. 6) Compute the release time as the difference between the time the release complete message was received and the time release message was send. Reporting Format: The results of the Connection Teardown Time tests SHOULD be reported in a form of a table. The rows SHOULD be labeled call accepted and call released. The columns SHOULD be labeled time message sent, time response received, and correct response. The elements of the columns 1 and 2 SHOULD be in seconds. The elements of column 3 SHOULD be be either True or False, indicating whether the particular condition was observed for each test. The table MUST also indicate the packet size in octets and traffic rate in packets per second as generated by the test device.3.4.3. Crankback Time
Objective: To determine the Crankback Time on the SUT as defined in RFC 2761 "Terminology for ATM Benchmarking". Procedure: 1) Set up the SUT and test device using the uni-directional passthrough configuration. 2) Create a PNNI signaling setup message, as described in Appendix C, specifying a DTL which is not blocked by the far end SUT. 3) Send the PNNI signaling setup message. Note the time the setup message was sent. Verify that the connect message has been received by the near-end switch. Note the time the connect message was received 4) Create a PNNI signaling setup message, as described in Appendix C, specifying a DTL which is blocked by the far end SUT. 5) Send the PNNI signaling release message. Note the time the release message was sent. Note the time the release complete
message was received. Note the time the near-end switch sends
it's own PNNI setup message (referred to as the near-end setup
message) specifying the non- blocked DTL.
6) Compute the crankback time as the difference between the time the
near-end setup message was received and the time release message
was send.
Reporting Format:
The results of the Crankback Time tests SHOULD be reported in a
form of a table. The rows SHOULD be labeled DTL call accepted and
call released. The columns SHOULD be labeled time message sent,
time response received, and correct response. The elements of the
columns 1 and 2 SHOULD be in seconds. The elements of column 3
SHOULD be be either True or False, indicating whether the
particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic
rate in packets per second as generated by the test device.
3.4.4. Route Update Response Time
Objective: To determine the Route Update Response Time on the SUT as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the uni-directional
passthrough configuration.
2) Create a PNNI PTSE as described in Appendix C, specifying a
routing topology. Verify that the routing tables on the far-end
and near-end switches are empty.
3) Send the PTSE message to the far-end switch. Note the time the
PTSE message was sent. Verify that the PTSE message has been
received by the far-end switch. Note the time the PTSE message
was received.
4) Create another PNNI PTSE as described in Appendix C, specifying a
change in the routing topology. Verify that the routing tables
on the far-end and near-end switches contain the previous PTSE
routes.
5) Send the PTSE message to the far-end switch. Note the time the
PTSE message was sent. Verify that the PTSE message has been
received by the far-end switch. Note the time the PTSE message
was received. Note the time the PTSE was sent to the near-end
switch. Note the time the PTSE message was received on the
near-end switch.
6) Compute the Route Update Response time as the difference between
the time the far-end PTSE message was sent and the time far-end
PTSE message was received by the near-end.
Reporting Format:
The results of the Route Update Response Time tests SHOULD be
reported in a form of a table. The rows SHOULD be labeled PTSE
call accepted, far-end PTSE message send, and near-end message
received. The columns SHOULD be labeled time message sent, time
response received, and correct response. The elements of the
columns 1 and 2 SHOULD be in seconds. The elements of column 3
SHOULD be be either True or False, indicating whether the
particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic
rate in packets per second as generated by the test device.
3.5. ATM Service: ILMI
3.5.1. MIB Alignment Time
Objective: To determine the MIB Alignment Time on the SUT as defined
in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Send a Cold Start message to the SUT. Note the time the message
was sent to the SUT. Verify that the Cold Start message has been
received by the SUT. Note the time the message was received.
3) Send a Get Request message to the SUT. Note the time the message
was sent to the SUT. Verify that the Get Request message has
been received by the SUT. Note the time the message was
received.
4) After all MIB elements are exchanged, verify that the final Get
Request message has been received by the SUT. Note the time the
message was send and received by the SUT.
5) Compute the MIB Alignment Time as the difference between the time
the Cold Start message was sent and the time the final Get
Request was received by the SUT.
Reporting Format:
The results of the MIB Alignment Time tests SHOULD be reported in
a form of a table. The rows SHOULD be labeled Cold Start Send,
Cold Start accepted, Final Get Request send, and Final Get Request
received. The columns SHOULD be labeled time message sent, time
response received, and correct response. The elements of the
columns 1 and 2 SHOULD be in seconds. The elements of column 3
SHOULD be be either True or False, indicating whether the
particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic
rate in packets per second as generated by the test device.
3.5.2. Address Registration Time
Objective: To determine the Address Registration Time on the SUT as
defined in RFC 2761 "Terminology for ATM Benchmarking".
Procedure:
1) Set up the SUT and test device using the bi-directional
configuration.
2) Send a Set Request message to the SUT. Note the time the message
was sent to the SUT. Verify that the Set Request message has
been received by the SUT. Note the time the message was
received.
3) Send a Get Request message to the SUT. Note the time the message
was sent to the SUT. Verify that the Get Request message has
been received by the SUT. Note the time the message was
received.
4) After all MIB elements are exchanged, verify that the final Get
Request message has been received by the SUT. Note the time the
message was send and received by the SUT.
5) Compute the Address Registration Time as the difference between
the time the Set Request message was sent and the time the final
Get Request was received by the SUT.
Reporting Format:
The results of the Address Registration Time tests SHOULD be
reported in a form of a table. The rows SHOULD be labeled Set
Request Send, Set Request accepted, Final Get Request send, and
Final Get Request received. The columns SHOULD be labeled time
message sent, time response received, and correct response. The
elements of the columns 1 and 2 SHOULD be in seconds. The
elements of column 3 SHOULD be be either True or False, indicating
whether the particular condition was observed for each test.
The table MUST also indicate the packet size in octets and traffic
rate in packets per second as generated by the test device.
4. Security Considerations
As this document is solely for the purpose of providing methodology
and describes neither a protocol nor an implementation, there are no
security considerations associated with this document.
5. Notices
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETFs procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
6. References
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998. [RFC2761] Dunn, J. and C. Martin, "Terminology for ATM Benchmarking", RFC 2761, February 2000. [AF-ILMI4.0] ATM Forum Integrated Local Management Interface Version 4.0, af-ilmi-0065.000, September 1996. [AF-TEST-0022] Introduction to ATM Forum Test Specifications, af- test-0022.00, December 1994. [AF-TM4.1] ATM Forum, Traffic Management Specification Version 4.1, af-tm-0121.00, April 1996. [AF-UNI3.1] ATM Forum, User Network Interface Specification Version 3.1, September 1994. [AF-UNI4.0] ATM Forum, User Network Interface Specification Version 4.0, July 1996.7. Authors' Addresses
Jeffrey Dunn Advanced Network Consultants, Inc. 4214 Crest Place Ellicott City, MD 21043, USA Phone: +1 (410) 750-1700 EMail: Jeffrey.Dunn@worldnet.att.net Cynthia Martin Advanced Network Consultants, Inc. 4214 Crest Place Ellicott City, MD 21043, USA Phone: +1 (410) 750-1700 EMail: Cynthia.E.Martin@worldnet.att.net
Appendix A: Ranges
ATM NSAP Network Prefix. 39 0000 0000 0000 0000 0000 0000-39 0000 0000 0000 0000 0000 00FF 39 0000 0000 0000 0000 0001 0000-39 0000 0000 0000 0000 0001 00FF 39 0000 0000 0000 0001 0000 0000 39 0000 0000 0000 0002 0020 0000 39 0000 0000 0300 0002 0030 0000 39 0000 0000 4000 0002 0060 0000 39 0000 0006 0060 0002 0030 0000 39 0000 0006 0050 0002 0030 0000 39 0000 0009 0300 0002 0030 0000 39 0000 00A0 0300 0002 0030 0000 39 0000 0B00 0300 0002 0030 0000 39 0000 C000 0300 0002 0030 0000 ATM NSAP End System Identifier. 1111 1111 1111 00-1111 1111 11FF 00 2222 2222 2000 00-2222 2222 2222 00 9999 999A 0000 00-9999 999C 0000 00Appendix B: Rates
PNNI Routing Update Size. 1) 1 PNNI routing entry update on non-aggregated addresses 2) 2 PNNI routing entry updates on non-aggregated addresses 3) 5 PNNI routing entry updates on non-aggregated addresses 4) 1 % of total available bandwidth or 1 Mb/s, whichever is less on non- aggregated addresses 5) 1 % of total available bandwidth or 1 Mb/s, whichever is less on of non-aggregated addresses and of aggregated addresses 6) 1 % of total available bandwidth or 1 Mb/s, whichever is less on aggregated addresses 7) 2 % of total available bandwidth or 2 Mb/s, whichever is less on non- aggregated addresses 8) 2 % of total available bandwidth or 2 Mb/s, whichever is less on of non-aggregated addresses and of aggregated addresses 9) 2 % of total available bandwidth or 2 Mb/s, whichever is less on aggregated addresses
PNNI Routing Update Repetition Interval.
Repetition Interval begins after initial PNNI routing table
stabilizes.
1) 1 update every 1 hour, for 24 hours
2) 1 update every 30 minutes, for 24 hours
3) 1 update every 5 minutes, for 1 hour
4) 1 update every 1 minute, for 15 minutes
5) 1 update every 30 seconds, for 5 minutes
6) 1 update every 30 seconds, for 1 minute
7) 1 update every 1 second, for 30 seconds
Maximum WAN Connection rates in packets per second (pps):
25.6 OC-3c OC-12c
IP Packet Size
octets/cells
44/2 30188 176603 706412
64/2 30188 176603 706412
128/3 20125 117735 470940
256/6 10062 58867 235468
1024/22 2744 16054 64216
1518/32 1886 11037 44148
2048/43 1404 8214 32856
4472/94 642 3757 15028
9180/192 314 1839 7356
Maximum LAN Connection rates in packets per second (pps):
DS-1 DS-3 E1 E3
IP Packet Size
octets/cells
44/2 1811 52133 2340 40000
64/2 1811 52133 2340 40000
128/3 1207 34755 1560 26666
256/6 603 17377 780 13333
1024/22 164 4739 212 3636
1518/32 113 3258 146 2500
2048/43 84 2424 108 1860
4472/94 38 1109 49 851
9180/192 18 543 24 416
Notes: 1. PDU size in cells is computed based on ceiling( ( PDU size in octets + 16) / 48). This assumes an 8 octet LLC/SNAP header and an 8 octet AAL/5 trailer. 2. Due to the number of possible configurations, IMA pps rates are not listed, but may be derived from the following formula: floor (IDCR/cells per packet), where cells per packet is computed as in note 1. 3. The following cell rates were used: DS-1 = 3622 cps (using ATM TC) E1 = 4681 cps 25.6 Mb/s = 60377 cps E3 = 80000 cps (using ATM TC) DS-3 = 104266 cps (using ATM TC) OC-3c = 353207 cps OC-12c = 1412828 cpsAppendix C: PDU's
TCP/IP over ATM Example 1. LLC: DSAP 0xAA (SNAP-SAP) SSAP 0xAA (SNAP-SAP) Control 0x03 (Unnumbered Information) SNAP: OUI 0x00-00-00 (Ethertype) PID 0x0800 (Internet Protocol) IP: Version = 4 Header length = 20 Type of service = 0 000. .... Precedence = Routine(0) ...0 .... Delay = Normal (0) .... 0... Throughput = Normal (0) .... .0.. Reliability = Normal (0) Packet length = 40 Id = 0 Fragmentation Info = 0x0000 .0.. .... .... .... Don't Fragment Bit = FALSE ..0. .... .... .... More Fragments Bit = FALSE ...0 0000 0000 0000 Fragment offset = 0 Time to live = 255 Protocol = TCP (6) Header checksum = F9CF Source address = 15.19.209.236 Destination address = 15.19.209.237 TCP: Source port = smtp (25) Destination port = smtp (25) Sequence number = 1 Ack number = 0 Data offset = 20 Flags = 0x02 ..0. .... URGENT Flag = FALSE ...0 .... ACK Flag = FALSE
.... 0... PUSH Flag = FALSE
.... .0.. RST Flag = FALSE
.... ..1. SYN Flag = TRUE
.... ...0 FIN Flag = FALSE
Window = 0
Checksum = EDAF
Urgent pointer = 00000000
TCP/IP over ATM Example 2.
LLC: DSAP 0xAA (SNAP-SAP)
SSAP 0xAA (SNAP-SAP)
Control 0x03 (Unnumbered Information)
SNAP: OUI 0x00-00-00 (Ethertype)
PID 0x0800 (Internet Protocol)
IP: Version = 4
Header length = 20
Type of service = 0
000. .... Precedence = Routine(0)
...0 .... Delay = Normal (0)
.... 0... Throughput = Normal (0)
.... .0.. Reliability = Normal (0)
Packet length = 40
Id = 0
Fragmentation Info = 0x0000
.0.. .... .... .... Don't Fragment Bit = FALSE
..0. .... .... .... More Fragments Bit = FALSE
...0 0000 0000 0000 Fragment offset = 0
Time to live = 255
Protocol = TCP (6)
Header checksum = F9CF
Source address = 15.19.209.236
Destination address = 15.19.209.237
TCP: Source port = ftp-data (20)
Destination port = 2000
Sequence number = 1
Ack number = 0
Data offset = 20
Flags = 0x02
..0. .... URGENT Flag = FALSE
...0 .... ACK Flag = FALSE
.... 0... PUSH Flag = FALSE
.... .0.. RST Flag = FALSE
.... ..1. SYN Flag = TRUE
.... ...0 FIN Flag = FALSE
Window = 0
Checksum = E5FD
Urgent pointer = 00000000
UDP/IP over ATM Example.
LLC: DSAP 0xAA (SNAP-SAP)
SSAP 0xAA (SNAP-SAP)
Control 0x03 (Unnumbered Information)
SNAP: OUI 0x00-00-00 (Ethertype)
PID 0x0800 (Internet Protocol)
IP: Version = 4
Header length = 20
Type of service = 0
000. .... Precedence = Routine(0)
...0 .... Delay = Normal (0)
.... 0... Throughput = Normal (0)
.... .0.. Reliability = Normal (0)
Packet length = 28
Id = 0
Fragmentation Info = 0x0000
.0.. .... .... .... Don't Fragment Bit = FALSE
..0. .... .... .... More Fragments Bit = FALSE
...0 0000 0000 0000 Fragment offset = 0
Time to live = 255
Protocol = ICMP (1)
Header checksum = F9E0
Source address = 15.19.209.236
Destination address = 15.19.209.237
ICMP: Type = Echo request (8)
Code = 0
Checksum = F7FF
Identifier = 0 (0x0)
Sequence Number = 0 (0x0)
RIP Routing Update over ATM.
-- DATAGRAM HEADER
offset data (hex) description
00 FF FF FF FF FF FF dest MAC address is broadcast
06 xx xx xx xx xx xx source hardware address
12 08 00 type
-- IP HEADER
14 45 IP version - 4, header length (4
byte units) - 5
15 00 service field
16 00 EE total length
18 00 00 ID
20 40 00 flags (3 bits) 4 (do not
fragment),
fragment offset-0
22 0A TTL
23 11 protocol - 17 (UDP)
24 C4 8D header checksum
26 xx xx xx xx source IP address
30 xx xx xx destination IP address
33 FF host part = FF for broadcast
-- UDP HEADER
34 02 08 source port 208 = RIP
36 02 08 destination port 208 = RIP
38 00 DA UDP message length
40 00 00 UDP checksum
-- RIP packet
42 02 command = response
43 01 version = 1
44 00 00 0
-- net 1
46 00 02 family = IP
48 00 00 0
50 xx xx xx net 1 IP address
53 00 net not node
54 00 00 00 00 0
58 00 00 00 00 0
62 00 00 00 07 metric 7
-- net 2
66 00 02 family = IP
68 00 00 0
70 xx xx xx net 2 IP address
73 00 net not node
74 00 00 00 00 0
78 00 00 00 00 0
82 00 00 00 07 metric 7
-- net 3
86 00 02 family = IP
88 00 00 0
90 xx xx xx net 3 IP address
93 00 net not node
94 00 00 00 00 0
98 00 00 00 00 0
102 00 00 00 07 metric 7
-- net 4
106 00 02 family = IP
108 00 00 0
110 xx xx xx net 4 IP address
113 00 net not node
114 00 00 00 00 0
118 00 00 00 00 0
122 00 00 00 07 metric 7
-- net 5
126 00 02 family = IP
128 00 00 0
130 00 net 5 IP address
133 00 net not node
134 00 00 00 00 0
138 00 00 00 00 0
142 00 00 00 07 metric 7
-- net 6
146 00 02 family = IP
148 00 00 0
150 xx xx xx net 6 IP address
153 00 net not node
154 00 00 00 00 0
158 00 00 00 00 0
162 00 00 00 07 metric 7
UNI 3.1 Signaling Setup Message Example. PCR will not allow CAC to
reject the call.
Protocol Discriminator : Q.93B UNI call control
Call Reference Length : 3
Call Reference Flag : orig
Call Reference Value : 0
Message Type : SETUP
Ext : last octet
Action Indicator : clear call
Message Length : 50
Information Element ID : ATM Traffic Descriptor
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 9
Cell Rate Subfield ID : forward peak CR(CLP=0+1)
Forward Peak Cell Rate : 1
Cell Rate Subfield ID : backward peak CR(CLP=0+1)
Backward Peak Cell Rate : 1
Cell Rate Subfield ID : best effort indicator
Information Element ID : Broadband Bearer Capability
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 2
Ext : last octet
Bearer Class : BCOB-X
Ext : last octet
Clipping Susceptibility : not susceptible to clipping
User Plane Connection CFG : point-to-point
Information Element ID : Called Party Number
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 21
Ext : last octet
Addressing/Numbering Plan : ISO NSAP addressing
ISO NSAP Address Octets : 3900000000000000000000000011111111111100
Information Element ID : Quality of Service Parameter
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 2
QoS Class Forward : QoS class 0 - unspecified
QoS Class Backward : QoS class 0 - unspecified
UNI 3.1 Signaling Setup Message Reject Example. PCR will allow
CAC to reject the call.
Protocol Discriminator : Q.93B UNI call control
Call Reference Length : 3
Call Reference Flag : orig
Call Reference Value : 0
Message Type : SETUP
Ext : last octet
Action Indicator : clear call
Message Length : 50
Information Element ID : ATM Traffic Descriptor
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 8
Cell Rate Subfield ID : forward peak CR(CLP=0+1)
Forward Peak Cell Rate : 300000
Cell Rate Subfield ID : backward peak CR(CLP=0+1)
Backward Peak Cell Rate : 300000
Information Element ID : Broadband Bearer Capability
Ext : last octet
Coding Standard : ITU-T standard
Flag : not significant
Action Indicator : clear call
IE Length : 3
Ext : another octet
Bearer Class : BCOB-X
Ext : last octet
Traffic Type : constant bit rate
Timing Requirements : end-to-end timing required
Ext : last octet
Clipping Susceptibility : not susceptible to clipping
User Plane Connection CFG : point-to-point
Information Element ID : Called Party Number
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 21
Ext : last octet
Addressing/Numbering Plan : ISO NSAP addressing
ISO NSAP Address Octets : 3900000000000000000000000011111111111100
Information Element ID : Quality of Service Parameter
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 2
QoS Class Forward : QoS class 0 - unspecified
QoS Class Backward : QoS class 0 - unspecified
UNI 3.1 Signaling Release Message, specifying a cause code of normal
call clearing.
Protocol Discriminator : Q.93B UNI call control
Call Reference Length : 3
Call Reference Flag : orig
Call Reference Value : 0
Message Type : RELEASE
Ext : last octet
Action Indicator : clear call
Message Length : 6
Information Element ID : Cause
Ext : last octet
Coding Standard : ITU-T standard
Action Indicator : clear call
IE Length : 2
Ext : last octet
Location : user
Ext : last octet
Cause Value : NE:normal call clearing
PNNI Signaling Setup Message, specifying a DTL which is not blocked
by the far end SUT.
Protocol Discriminator : PNNI signalling
Call Reference Length : 3
Call Reference Flag : from
Message Type : SETUP
Ext : last octet
Pass Along Request : no pass along request
Action Indicator : clear call
Message Length : 56
Information Element ID : ATM Traffic Descriptor
Ext : last octet
Coding Standard : ITU-T standardized
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 0
Information Element ID : Broadband Bearer Capability
Ext : last octet
Coding Standard : ITU-T standardized
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 3
Ext : another octet
Bearer Class : BCOB-X
Ext : last octet
ATM Transfer Capability : reserved for bwd compatibility
Ext : last octet
Clipping Susceptibility : not susceptible to clipping
User Plane Connection cfg : point-to-point
Information Element ID : Called Party Number
Ext : last octet
Coding Standard : ITU-T standardized
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 8
Ext : last octet
Type of Number : unknown
Addressing/Numbering Plan : ATM endsystem address
ATM Endsystem Address Oct : 11111111111101
Information Element ID : Designated Transit List
Ext : last octet
Coding Standard : ATM Forum specific
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 29
Current Transit Pointer : 0
Logical Node/Port Indicat : Logical Node/Port Indicator
Logical Node Identifier : 3900000000000000000000000011111111111100
PNNI Signaling Setup Message Reject, specifying a DTL which is
blocked by the far end SUT.
Protocol Discriminator : PNNI signalling
Call Reference Length : 3
Call Reference Flag : from
Call Reference Value : 0
Message Type : SETUP
Ext : last octet
Pass Along Request : no pass along request
Action Indicator : clear call
Message Length : 56
Information Element ID : ATM Traffic Descriptor
Ext : last octet
Coding Standard : ITU-T standardized
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 0
Information Element ID : Broadband Bearer Capability
Ext : last octet
Coding Standard : ITU-T standardized
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 3
Bearer Class : BCOB-X
Ext : last octet
ATM Transfer Capability : reserved for bwd compatibility
Ext : last octet
Clipping Susceptibility : not susceptible to clipping
User Plane Connection cfg : point-to-point
Information Element ID : Called Party Number
Ext : last octet
Coding Standard : ITU-T standardized
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 8
Ext : last octet
Addressing/Numbering Plan : ATM endsystem address
ATM Endsystem Address Oct : 11111111111101
Information Element ID : Designated Transit List
Ext : last octet
Coding Standard : ATM Forum specific
Pass Along Request : no pass along request
Action Indicator : clear call
IE Length : 29
Current Transit Pointer : 0
Logical Node/Port Indicat : Logical Node/Port Indicator
Logical Node Identifier : 3900000000000000000000000011111111111100
PNNI Far End Request Message.
Header: Packet Type 5 (PTSE REQUEST)
Packet Length 40
Protocol Version 1
Newest Version Supported 1
Oldest Version Supported 0
Reserved 0
IG: Information Group Type 513 (Requested PTSE Header)
Information Group Length 32
Originating Node ID
00013900-00000000-00000000-00000011-11111111-1100
PTSE Request Count 1
PTSE Identifier 0
PNNI PTSE, specifying a routing topology.
Header: Packet Type 4 (DATABASE SUMMARY)
Packet Length 76
Protocol Version 1
Newest Version Supported 1
Oldest Version Supported 0
Reserved 0
Initialize (I)Bit 1 (during init. of DB syn
process)
More (M)Bit 1 (PTSEs to summarize)
Master (MS)Bit 1 (both nodes)
Reserved 0
Reserved 0
DS Sequence Number 0
IG: Information Group Type 512 (Nodal PTSE Summaries)
Information Group Length 60
Originating Node ID
00013900-00000000-00000000-00000011-11111111-1100
Originating Node's Peer Group 00000000-00000000-00000000-
0001
Reserved 0
PTSE Summary Count 1
PTSE Type 0
Reserved 0
PTSE Identifier 0
PTSE Sequence Number 0
PTSE Checksum 0
PTSE Remaining Lifetime 0
PNNI PTSE Update, specifying a change in the routing topology.
Header: Packet Type 2 (PTSP)
Packet Length 96
Protocol Version 1
Newest Version Supported 1
Oldest Version Supported 0
Reserved 0
Originating Node ID
00013900-00000000-00000000-00000011-11111111-1100
Originating Node's Peer Group 00000000-00000000-00000000-
0001
IG: Information Group Type 64 (PTSE)
Information Group Length 52
PTSE Type 0
Reserved 0
PTSE Identifier 0
PTSE Sequence Number 0
PTSE Checksum 42252
PTSE Remaining Lifetime 3600
IG: Information Group Type 224 (Internal Reachable ATM
Addresses)
Information Group Length 32
VP Capability Flag 1 (VPCs supported)
Reserved 0
Reserved 0
Port ID 0
Scope of Advertisement 96
Address Information Length 14
Address Information Count 1
Prefix Length 13
Reachable Address Prefix 39000000-00000000-00000000-01
Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.