1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
Network Working Group M. Tuexen
Request for Comments: 5133 Muenster Univ. of Applied Sciences
Updates: 4233 K. Morneault
Category: Standards Track Cisco Systems, Inc.
December 2007
Terminal Endpoint Identifier (TEI) Query Request Number Change
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Integrated Services Digital Network (ISDN) Q.921-User Adaptation
Layer (IUA) Protocol, described in RFC 4233, defines the message type
of Terminal Endpoint Identifier (TEI) Query Request messages as 5.
However, this number is already being used by the Digital Private
Network Signaling System (DPNSS)/Digital Access Signaling System 2
(DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.
This document updates RFC 4233 such that the message type of TEI
Query Request messages is 8.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. New Message Type of the TEI Query Message . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 2
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 2
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 2
7. Normative References . . . . . . . . . . . . . . . . . . . . . 3
Tuexen & Morneault Standards Track [Page 1]
^L
RFC 5133 TEI Query Request Number Change December 2007
1. Introduction
The Integrated Services Digital Network (ISDN) Q.921-User Adaptation
Layer (IUA) protocol, described in [RFC3057], does not define a
Terminal Endpoint Identifier (TEI) Query Request message. The
Digital Private Network Signaling System (DPNSS)/Digital Access
Signaling System 2 (DASS 2) Extensions (DUA) to the IUA Protocol,
described in [RFC4129], introduces Data Link Connection (DLC) Status
messages of type 5, 6, and 7. Then, [RFC4233] was published, which
updates [RFC3057]. [RFC4233] also introduces the TEI Query Request
message and uses the message type of 5 for it. This makes it
impossible to differentiate the DLC Status request from a TEI Query
Request.
This document updates [RFC4233].
2. 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 [RFC2119].
3. New Message Type of the TEI Query Message
This document updates [RFC4233] by introducing the following change:
Terminal Endpoint Identifier (TEI) Query messages MUST be encoded
with a message type of 8 instead of 5 as described in [RFC4233].
4. IANA Considerations
In the "Message Types" section of the "Signaling User Adaptation
Layer Assignments" registry, IANA has reserved the message type 8 of
Management Messages for Terminal Endpoint Identifier (TEI) Query
Request messages.
5. Security Considerations
This document does not require any security considerations in
addition to the ones given in [RFC4233].
6. Acknowledgments
The authors wish to thank Jon Peterson and Christian Vogt for their
invaluable comments.
Tuexen & Morneault Standards Track [Page 2]
^L
RFC 5133 TEI Query Request Number Change December 2007
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3057] Morneault, K., Rengasami, S., Kalla, M., and G.
Sidebottom, "ISDN Q.921-User Adaptation Layer", RFC 3057,
February 2001.
[RFC4129] Mukundan, R., Morneault, K., and N. Mangalpally, "Digital
Private Network Signaling System (DPNSS)/Digital Access
Signaling System 2 (DASS 2) Extensions to the IUA
Protocol", RFC 4129, September 2005.
[RFC4233] Morneault, K., Rengasami, S., Kalla, M., and G.
Sidebottom, "Integrated Services Digital Network (ISDN)
Q.921-User Adaptation Layer", RFC 4233, January 2006.
Authors' Addresses
Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany
EMail: tuexen@fh-muenster.de
Ken Morneault
Cisco Systems, Inc.
13615 Dulles Technology Drive
Herndon, VA 20171
US
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Tuexen & Morneault Standards Track [Page 3]
^L
RFC 5133 TEI Query Request Number Change December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF 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
this 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. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR 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
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Tuexen & Morneault Standards Track [Page 4]
^L
|
