idnits 2.17.1 draft-rfced-info-dudley-00.txt: -(57): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(90): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(93): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(111): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(139): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(156): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(166): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(326): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(355): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(381): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(437): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(446): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(492): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(547): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(594): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(601): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(655): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(710): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(765): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(799): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(800): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(821): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(875): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(929): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(962): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(985): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1040): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1094): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1149): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1180): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1181): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1183): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1185): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1188): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1190): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1192): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1194): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1195): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1196): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1198): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1200): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1204): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1207): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1209): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1211): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1213): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1216): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1217): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1219): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1220): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1222): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1224): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1227): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1228): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1229): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1233): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1237): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1238): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1241): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1242): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1243): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1244): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1245): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1247): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1248): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1250): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1252): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1253): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1254): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1260): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1261): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1263): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1265): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1266): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1267): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1269): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1273): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1274): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1280): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1281): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1314): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1370): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1402): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1405): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1406): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1407): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1409): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1411): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1426): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1432): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1469): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1471): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1473): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1475): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1477): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1479): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1481): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1483): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1485): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1487): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1489): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1494): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1525): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1550): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1551): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1580): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1592): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1636): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1638): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1692): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1699): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1703): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1708): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1712): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1716): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1723): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1729): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1743): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1758): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1762): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1763): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1764): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1765): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1766): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1767): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1771): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1773): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1776): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1779): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1782): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1786): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1787): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1790): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1791): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1794): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1797): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1798): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1801): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1802): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1805): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1806): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1809): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1811): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1813): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1816): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1817): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1818): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1819): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1820): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1821): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1824): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1826): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1827): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1828): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1829): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1833): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1835): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1838): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1841): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1844): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1848): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1849): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1850): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1851): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1854): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1855): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1856): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1859): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1861): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1864): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1867): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1868): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1871): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1872): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1875): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1877): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1879): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1882): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1883): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1884): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1885): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1888): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1889): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1890): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1891): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1921): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 306 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9560 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES AUGUST 1998 INTERNET DRAFT 2 Network Working Group G. Dudley 3 INTERNET DRAFT IBM 4 Category: Informational February 1998 6 High Performance Routing in IP Networks 7 APPN Implementers' Workshop Closed Pages Document 8 10 Status of This Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 "work in progress." 23 To learn the current status of any Internet-Draft, please check 24 the "1id-abstracts.txt" listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. 31 (R) 'Advanced Peer-to-Peer Networking' and 'APPN' are trademarks of the 32 IBM Corporation. 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Table of Contents 40 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 41 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 2 43 2.0 IP as a Data Link Control (DLC) for HPR . . . . . . . . . . . 3 44 2.1 Use of UDP and IP . . . . . . . . . . . . . . . . . . . . . . 3 45 2.2 Node Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 46 2.3 Logical Link Control (LLC) Used for IP . . . . . . . . . . . . 6 47 2.3.1 LDLC Liveness . . . . . . . . . . . . . . . . . . . . . . 7 48 2.3.1.1 Option to Reduce Liveness Traffic . . . . . . . . . . 7 49 2.4 IP Port Activation . . . . . . . . . . . . . . . . . . . . . . 8 50 2.4.1 Maximum BTU Sizes for HPR/IP . . . . . . . . . . . . . . . 10 51 2.5 IP Transmission Groups (TGs) . . . . . . . . . . . . . . . . . 10 52 2.5.1 Regular TGs . . . . . . . . . . . . . . . . . . . . . . . 10 53 2.5.1.1 Limited Resources and Auto-Activation . . . . . . . . 15 54 2.5.2 IP Connection Networks . . . . . . . . . . . . . . . . . . 16 55 2.5.2.1 Establishing IP Connection Networks . . . . . . . . . 17 57 Dudley Informational �Page 1� 58 2.5.2.2 IP Connection Network Parameters . . . . . . . . . . . 19 59 2.5.2.3 Sharing of TGs . . . . . . . . . . . . . . . . . . . . 20 60 2.5.2.4 Minimizing RSCV Length . . . . . . . . . . . . . . . . 21 61 2.5.3 Unsuccessful IP Link Activation . . . . . . . . . . . . . 22 62 2.6 IP Throughput Characteristics . . . . . . . . . . . . . . . . 24 63 2.6.1 IP Prioritization . . . . . . . . . . . . . . . . . . . . 24 64 2.6.2 APPN Transmission Priority and COS . . . . . . . . . . . . 25 65 2.6.3 Default TG Characteristics . . . . . . . . . . . . . . . . 26 66 2.6.4 SNA-Defined COS Tables . . . . . . . . . . . . . . . . . . 28 67 2.6.5 Route Setup over HPR/IP links . . . . . . . . . . . . . . 28 68 2.6.6 Access Link Queueing . . . . . . . . . . . . . . . . . . . 29 69 2.7 Port Link Activation Limits . . . . . . . . . . . . . . . . . 29 70 2.8 Network Management . . . . . . . . . . . . . . . . . . . . . . 30 71 2.9 IPv4-to-IPv6 Migration . . . . . . . . . . . . . . . . . . . . 31 73 3.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 75 4.0 Security Considerations . . . . . . . . . . . . . . . . . . . 32 77 5.0 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 79 6.0 Appendix - Packet Format . . . . . . . . . . . . . . . . . . . 33 80 6.1 HPR Use of IP Formats . . . . . . . . . . . . . . . . . . . . 34 81 6.1.1 IP Format for LLC Commands and Responses . . . . . . . . . 34 82 6.1.2 IP Format for NLPs in UI Frames . . . . . . . . . . . . . 36 84 7.0 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 37 86 1.0 Introduction 88 The architecture for APPN nodes is specified in "Systems Network 89 Architecture Advanced Peer-to-Peer Networking Architecture Reference" 90 �1�. A set of APPN enhancements for High Performance Routing (HPR) is 91 specified in "Systems Network Architecture Advanced Peer-to-Peer 92 Networking High Performance Routing Architecture Reference, Version 3.0" 93 �2�. The formats associated with these architectures are specified in 94 "Systems Network Architecture Formats" �3�. This memo assumes the 95 reader is familiar with these specifications. 97 This memo defines a method with which HPR nodes can use IP networks for 98 communication, and the enhancements to APPN required by this method. 99 This memo also describes an option set that allows the use of the APPN 100 connection network model to allow HPR nodes to use IP networks for 101 communication without having to predefine link connections. 103 1.1 Requirements 105 The following are the requirements for the architecture specified in 106 this memo: 108 1. Facilitate APPN product interoperation in IP networks by documenting 109 agreements such as the choice of the logical link control (LLC). 111 Dudley Informational �Page 2� 112 2. Reduce system definition (e.g., by extending the connection network 113 model to IP networks) -- Connection network support is an optional 114 function. 116 3. Use class of service (COS) to retain existing path selection and 117 transmission priority services in IP networks; extend transmission 118 priority function to include IP networks. 120 4. Allow customers the flexibility to design their networks for low 121 cost and high performance. 123 5. Use HPR functions to improve both availability and scalability over 124 existing integration techniques such as Data Link Switching (DLSw) 125 which is specified in RFC 1795 �4� and RFC 2166 �5�. 127 2.0 IP as a Data Link Control (DLC) for HPR 129 This memo specifies the use of IP and UDP as a new DLC that can be 130 supported by APPN nodes with the three HPR option sets: HPR (option set 131 1400), Rapid Transport Protocol (RTP) (option set 1401), and Control 132 Flows over RTP (option set 1402). Logical Data Link Control (LDLC) 133 Support (option set 2006) is also a prerequisite. 135 RTP is a connection-oriented, full-duplex protocol designed to transport 136 data in high-speed networks. HPR uses RTP connections to transport SNA 137 session traffic. RTP provides reliability (i.e., error recovery via 138 selective retransmission), in-order delivery (i.e., a first-in-first-out 139 �FIFO� service provided by resequencing data that arrives out of order), 140 and adaptive rate-based (ARB) flow/congestion control. Because RTP 141 provides these functions on an end-to-end basis, it eliminates the need 142 for these functions on the link level along the path of the connection. 143 The result is improved overall performance for HPR. For a more complete 144 description of RTP, see Appendix F of �2�. 146 This new DLC (referred to as the native IP DLC) allows customers to take 147 advantage of APPN/HPR functions such as class of service (COS) and ARB 148 flow/congestion control in the IP environment. HPR links established 149 over the native IP DLC are referred to as HPR/IP links. The following 150 sections describe in detail the considerations and enhancements 151 associated with the native IP DLC. 153 2.1 Use of UDP and IP 155 The native IP DLC will use the User Datagram Protocol (UDP) defined in 156 RFC 768 �6� and the Internet Protocol (IP) version 4 defined in RFC 791 157 �7�. 159 Typically, access to UDP is provided by a sockets API. UDP provides an 160 unreliable connectionless delivery service using IP to transport 161 messages between nodes. UDP has the ability to distinguish among 162 multiple destinations within a given node, and allows port-number-based 163 prioritization in the IP network. UDP provides detection of corrupted 164 packets, a function required by HPR. Higher-layer protocols such as HPR 166 Dudley Informational �Page 3� 167 are responsible for handling problems of message loss, duplication, 168 delay, out-of-order delivery, and loss of connectivity. UDP is adequate 169 because HPR uses RTP to provide end-to-end error recovery and in-order 170 delivery; in addition, LDLC detects loss of connectivity. The 171 Transmission Control Protocol (TCP) was not chosen for the native IP DLC 172 because the additional services provided by TCP such as error recovery 173 are not needed. Furthermore, the termination of TCP connections would 174 require additional node resources (control blocks, buffers, timers, and 175 retransmit queues) and would, thereby, reduce the scalability of the 176 design. 178 The UDP header has four two-byte fields. The UDP Destination Port is a 179 16-bit field that contains the UDP protocol port number used to 180 demultiplex datagrams at the destination. The UDP Source Port is a 181 16-bit field that contains the UDP protocol port number that specifies 182 the port to which replies should be sent when other information is not 183 available. A zero setting indicates that no source port number 184 information is being provided. When used with the native IP DLC, this 185 field is not used to convey a port number for replies; moreover, the 186 zero setting is not used. IANA has registered port numbers 12000 187 through 12004 for use in these two fields by the native IP DLC; use of 188 these port numbers allows prioritization in the IP network. For more 189 details of the use of these fields, see 2.6.1, "IP Prioritization" on 190 page 24. 192 The UDP Checksum is a 16-bit optional field that provides coverage of 193 the UDP header and the user data; it also provides coverage of a 194 pseudo-header that contains the source and destination IP addresses. 195 The UDP checksum is used to guarantee that the data has arrived intact 196 at the intended receiver. When the UDP checksum is set to zero, it 197 indicates that the checksum was not calculated and should not be checked 198 by the receiver. Use of the checksum is recommended for use with the 199 native IP DLC. 201 IP provides an unreliable, connectionless delivery mechanism. The IP 202 protocol defines the basic unit of data transfer through the IP network, 203 and performs the routing function (i.e., choosing the path over which 204 data will be sent). In addition, IP characterizes how "hosts" and 205 "gateways" should process packets, the circumstances under which error 206 messages are generated, and the conditions under which packets are 207 discarded. An IP version 4 header contains an 8-bit Type of Service 208 field that specifies how the datagram should be handled. As defined in 209 RFC 1349 �8�, the type-of-service byte contains two defined fields. The 210 3-bit precedence field allows senders to indicate the priority of each 211 datagram. The 4-bit type of service field indicates how the network 212 should make tradeoffs between throughput, delay, reliability, and cost. 213 The 8-bit Protocol field specifies which higher-level protocol created 214 the datagram. When used with the native IP DLC, this field is set to 17 215 which indicates the higher-layer protocol is UDP. 217 2.2 Node Structure 219 Figure 1 on page 6 shows a possible node functional decomposition for 221 Dudley Informational �Page 4� 222 transport of HPR traffic across an IP network. There will be variations 223 in different platforms based on platform characteristics. 225 The native IP DLC includes a DLC manager, one LDLC component for each 226 link, and a link demultiplexor. Because UDP is a connectionless 227 delivery service, there is no need for HPR to activate and deactivate 228 lower-level connections. 230 The DLC manager activates and deactivates a link demultiplexor for each 231 port and an instance of LDLC for each link established in an IP network. 232 Multiple links (e.g., one defined link and one dynamic link for 233 connection network traffic) may be established between a pair of IP 234 addresses. Each link is identified by the source and destination IP 235 addresses in the IP header and the source and destination service access 236 point (SAP) addresses in the IEEE 802.2 LLC header (see 6.0, "Appendix - 237 Packet Format" on page 33); the link demultiplexor passes incoming 238 packets to the correct instance of LDLC based on these identifiers. 239 Moreover, the IP address pair associated with an active link and used in 240 the IP header may not change. 242 LDLC also provides other functions (for example, reliable delivery of 243 Exchange Identification �XID� commands). Error recovery for HPR RTP 244 packets is provided by the protocols between the RTP endpoints. 246 The network control layer (NCL) uses the automatic network routing (ANR) 247 information in the HPR network header to either pass incoming packets to 248 RTP or an outgoing link. 250 All components are shown as single entities, but the number of logical 251 instances of each is as follows: 253 o DLC manager -- 1 per node 255 o LDLC -- 1 per link 257 o Link demultiplexor -- 1 per port 259 o NCL -- 1 per node (or 1 per port for efficiency) 261 o RTP -- 1 per RTP connection 263 o UDP -- 1 per port 265 o IP -- 1 per port 267 Products are free to implement other structures. Products implementing 268 other structures will need to make the appropriate modifications to the 269 algorithms and protocol boundaries shown in this document. 271 Dudley Informational �Page 5� 272 ------------------------------------------------------------------------ 274 -* 275 *-------------* *-------* � 276 �Configuration� � Path � � 277 � Services � �Control� � 278 *-------------* *-------* � 279 A A A � 280 � � � � 281 � � V � 282 � � *-----* � APPN/HPR 283 � � � RTP � � 284 � � *-----* � 285 � � A � 286 � � � � 287 � � V � 288 � � *-----* � 289 � � � NCL � � 290 � � *-----* � 291 � *------------* A -* 292 � � � 293 V V V -* 294 *---------* *---------* � 295 � DLC �--->� LDLC � � 296 � manager � � � � 297 *---------* *---------* � 298 � A � � IP DLC 299 *-----------* � *----* � 300 V � � � 301 *---------* � � 302 � LINK � � � 303 � DEMUX � � � 304 *---------* � � 305 A *-* -* 306 � � 307 � V 308 *---------* 309 � UDP � 310 *---------* 311 A 312 � 313 V 314 *---------* 315 � IP � 316 *---------* 318 ------------------------------------------------------------------------ 319 Figure 1. HPR/IP Node Structure 321 2.3 Logical Link Control (LLC) Used for IP 323 Logical Data Link Control (LDLC) is used by the native IP DLC. LDLC is 324 defined in �2�. LDLC uses a subset of the services defined by IEEE 326 Dudley Informational �Page 6� 327 802.2 LLC type 2 (LLC2). LDLC uses only the TEST, XID, DISC, DM, and UI 328 frames. 330 LDLC was defined to be used in conjunction with HPR (with the HPR 331 Control Flows over RTP option set 1402) over reliable links that do not 332 require link-level error recovery. Most frame loss in IP networks (and 333 the underlying frame networks) is due to congestion, not problems with 334 the facilities. When LDLC is used on a link, no link-level error 335 recovery is available; as a result, only RTP traffic is supported by the 336 native IP DLC. Using LDLC eliminates the need for LLC2 and its 337 associated cost (adapter storage, longer path length, etc.). 339 2.3.1 LDLC Liveness 341 LDLC liveness (using the LDLC TEST command and response) is required 342 when the underlying subnetwork does not provide notification of 343 connection outage. Because UDP is connectionless, it does not provide 344 outage notification; as a result, LDLC liveness is required for HPR/IP 345 links. 347 Liveness should be sent periodically on active links except as described 348 in the following subsection when the option to reduce liveness traffic 349 is implemented. The default liveness timer period is 10 seconds. When 350 the defaults for the liveness timer and retry timer (15 seconds) are 351 used, the period between liveness tests is smaller than the time 352 required to detect failure (retry count multiplied by retry timer 353 period) and may be smaller than the time for liveness to complete 354 successfully (on the order of round-trip delay). When liveness is 355 implemented as specified in the LDLC finite-state machine (see �2�) this 356 is not a problem because the liveness protocol works as follows: The 357 liveness timer is for a single link. The timer is started when the link 358 is first activated and each time a liveness test completes successfully. 359 When the timer expires, a liveness test is performed. When the link is 360 operational, the period between liveness tests is on the order of the 361 liveness timer period plus the round-trip delay. 363 For each implementation, it is necessary to check if the liveness 364 protocol will work in a satisfactory manner with the default settings 365 for the liveness and retry timers. If, for example, the liveness timer 366 is restarted immediately upon expiration, then a different default for 367 the liveness timer should be used. 369 2.3.1.1 Option to Reduce Liveness Traffic 371 In some environments, it is advantageous to reduce the amount of 372 liveness traffic when the link is otherwise idle. (For example, this 373 could allow underlying facilities to be temporarily deactivated when not 374 needed.) As an option, implementations may choose not to send liveness 375 when the link is idle (i.e., when data was neither sent nor received 376 over the link while the liveness timer was running). (If the 377 implementation is not aware of whether data has been received, liveness 378 testing may be stopped while data is not being sent.) However, the RTP 379 connections also have a liveness mechanism which will generate traffic. 381 Dudley Informational �Page 7� 382 Some implementations of RTP will allow setting a large value for the 383 ALIVE timer, thus reducing the amount of RTP liveness traffic. 385 If LDLC liveness is turned off while the link is idle, one side of the 386 link may detect a link failure much earlier than the other. This can 387 cause the following problems: 389 o If a node that is aware of a link failure attempts to reactivate the 390 link, the partner node (unaware of the link failure) may reject the 391 activation as an unsupported parallel link between the two ports. 393 o If a node that is unaware of an earlier link failure sends data 394 (including new session activations) on the link, it may be discarded 395 by a node that detected the earlier failure and deactivated the 396 link. As a result, session activations would fail. 398 The mechanisms described below can be used to remedy these problems. 399 These mechanisms are needed only in a node not sending liveness when the 400 link is idle; thus, they would not be required of a node not 401 implementing this option that just happened to be adjacent to a node 402 implementing the option. 404 o (Mandatory unless the node supports multiple active defined links 405 between a pair of HPR/IP ports and supports multiple active dynamic 406 links between a pair of HPR/IP ports.) Anytime a node rejects the 407 activation of an HPR/IP link as an unsupported parallel link between 408 a pair of HPR/IP ports (sense data X'10160045' or X'10160046'), it 409 should perform liveness on any active link between the two ports 410 that is using a different SAP pair. Thus, if the activation was not 411 for a parallel link but rather was a reactivation because one of 412 these active links had failed, the failed link will be detected. 413 (If the SAP pair for the link being activated matches the SAP pair 414 for an active link, a liveness test would succeed because the 415 adjacent node would respond for the link being activated.) A simple 416 way to implement this function is for LDLC, upon receiving an 417 activation XID, to run liveness on all active links with a matching 418 IP address pair and a different SAP pair. 420 o (Mandatory) Anytime a node receives an activation XID with an IP 421 address pair and a SAP pair that match those of an active link, it 422 should deactivate the active link and allow it to be reestablished. 423 A timer is required to prevent stray XIDs from deactivating an 424 active link. 426 o (Recommended) A node should attempt to reactivate an HPR/IP link 427 before acting on an LDLC-detected failure. This mechanism is 428 helpful in preventing session activation failures in scenarios where 429 the other side detected a link failure earlier, but the network has 430 recovered. 432 2.4 IP Port Activation 434 The node operator (NO) creates a native IP DLC by issuing DEFINE_DLC(RQ) 435 (containing customer-configured parameters) and START_DLC(RQ) commands 437 Dudley Informational �Page 8� 438 to the node operator facility (NOF). NOF, in turn, passes 439 DEFINE_DLC(RQ) and START_DLC(RQ) signals to configuration services (CS), 440 and CS creates the DLC manager. Then, the node operator can define a 441 port by issuing DEFINE_PORT(RQ) (also containing customer-configured 442 parameters) to NOF with NOF passing the associated signal to CS. 444 A node with adapters attached to multiple IP subnetworks may represent 445 the multiple adapters as a single HPR/IP port. However, in that case, 446 the node associates a single IP address with that port. RFC 1122 �9� 447 requires that a node with multiple adapters be able to use the same 448 source IP address on outgoing UDP packets regardless of the adapter used 449 for transmission. 451 *----------------------------------------------* 452 � NOF CS DLC � 453 *----------------------------------------------* 454 . DEFINE_DLC(RQ) . 455 1 o----------------->o 456 . DEFINE_DLC(RSP) � 457 2 o<-----------------* 458 . START_DLC(RQ) . create 459 3 o----------------->o------------------->o 460 . START_DLC(RSP) � . 461 4 o<-----------------* . 462 . DEFINE_PORT(RQ) . . 463 5 o----------------->o . 464 . DEFINE_PORT(RSP) � . 465 6 o<-----------------* . 467 Figure 2. IP Port Activation 469 The following parameters are received in DEFINE_PORT(RQ): 471 o Port name 473 o DLC name 475 o Port type (if IP connection networks are supported, set to shared 476 access transport facility �SATF�; otherwise, set to switched) 478 o Link station role (set to negotiable) 480 o Maximum receive BTU size (default is 1469 �1500 less an allowance 481 for the IP, UDP, and LLC headers�) 483 o Maximum send BTU size (default is 1469 �1500 less an allowance for 484 the IP, UDP, and LLC headers�) 486 o Link activation limits (total, inbound, and outbound) 488 o IPv4 supported (set to yes) 490 o The local IPv4 address (required if IPv4 is supported) 492 Dudley Informational �Page 9� 493 o IPv6 supported (set to no; may be set to yes in the future; see 2.9, 494 "IPv4-to-IPv6 Migration" on page 31) 496 o The local IPv6 address (required if IPv6 is supported) 498 o Retry count for LDLC (default is 3) 500 o Retry timer period for LDLC (default is 15 seconds; a smaller value 501 such as 10 seconds can be used for a campus network) 503 o LDLC liveness timer period (default is 10 seconds; see 2.3.1, "LDLC 504 Liveness" on page 7) 506 o IP precedence (the setting of the 3-bit field within the Type of 507 Service byte of the IP header for the LLC commands such as XID and 508 for each of the APPN transmission priorities; the defaults are given 509 in 2.6.1, "IP Prioritization" on page 24.) 511 2.4.1 Maximum BTU Sizes for HPR/IP 513 When IP datagrams are larger than the underlying physical links support, 514 IP performs fragmentation. When HPR/IP links are established, the 515 default maximum basic transmission unit (BTU) sizes are 1469 bytes, 516 which corresponds to the typical IP maximum transmission unit (MTU) size 517 of 1500 bytes supported by routers. 1469 is 1500 less 20 bytes for the 518 IP header, 8 bytes for the UDP header, and 3 bytes for the IEEE 802.2 519 LLC header. The IP header is larger than 20 bytes when optional fields 520 are included; smaller maximum BTU sizes should be configured if optional 521 IP header fields are used in the IP network. For IPv6, the default is 522 reduced to 1449 bytes to allow for the typical IPv6 header size of 40 523 bytes. Smaller maximum BTU sizes (but not less than 768) should be used 524 to avoid fragmentation when necessary. Larger BTU sizes should be used 525 to improve performance when the customer's IP network supports a 526 sufficiently large IP MTU size. The maximum receive and send BTU sizes 527 are passed to CS in DEFINE_PORT(RQ). These maximum BTU sizes can be 528 overridden in DEFINE_CN_TG(RQ) or DEFINE_LS(RQ). 530 The Flags field in the IP header should be set to allow fragmentation. 531 Some products will not be able to control the setting of the bit 532 allowing fragmentation; in that case, fragmentation will most likely be 533 allowed. Although fragmentation is slow and prevents prioritization 534 based on UDP port numbers, it does allow connectivity across paths with 535 small MTU sizes. 537 2.5 IP Transmission Groups (TGs) 539 2.5.1 Regular TGs 541 Regular HPR TGs may be established in IP networks using the native IP 542 DLC architecture. Each of these TGs is composed of one or more HPR/IP 543 links. Configuration services (CS) identifies the TG with the 544 destination control point (CP) name and TG number; the destination CP 545 name may be configured or learned via XID, and the TG number, which may 547 Dudley Informational �Page 10� 548 be configured, is negotiated via XID. For auto-activatable links, the 549 destination CP name and TG number must be configured. 551 When multiple links (dynamic or defined) are established between a pair 552 of IP ports (each associated with a single IP address), an incoming 553 packet can be mapped to its associated link using the IP address pair 554 and the service access point (SAP) address pair. If a node receives an 555 activation XID for a defined link with an IP address pair and a SAP pair 556 that are the same as for an active defined link, that node can assume 557 that the link has failed and that the partner node is reactivating the 558 link. In such a case as an optimization, the node receiving the XID can 559 take down the active link and allow the link to be reestablished in the 560 IP network. Because UDP packets can arrive out of order, implementation 561 of this optimization requires the use of a timer to prevent a stray XID 562 from deactivating an active link. 564 Support for multiple defined links between a pair of HPR/IP ports is 565 optional. There is currently no value in defining multiple HPR/IP links 566 between a pair of ports. In the future if HPR/IP support for the 567 Resource ReSerVation Protocol (RSVP) �10� is defined, it may be 568 advantageous to define such parallel links to segregate traffic by COS 569 on RSVP "sessions." Using RSVP, HPR would be able to reserve bandwidth 570 in IP networks. An HPR logical link would be mapped to an RSVP 571 "session" that would likely be identified by either a specific 572 application-provided UDP port number or a dynamically-assigned UDP port 573 number. 575 When multiple defined HPR/IP links between ports are not supported, an 576 incoming activation for a defined HPR/IP link may be rejected with sense 577 data X'10160045' if an active defined HPR/IP link already exists between 578 the ports. If the SAP pair in the activation XID matches the SAP pair 579 for the existing link, the optimization described above may be used 580 instead. 582 If parallel defined HPR/IP links between ports are not supported, an 583 incoming activation XID is mapped to the defined link station (if it 584 exists) associated with the port on the adjacent node using the source 585 IP address in the incoming activation XID. This source IP address 586 should be the same as the destination IP address associated with the 587 matching defined link station. (They may not be the same if the 588 adjacent node has multiple IP addresses, and the configuration was not 589 coordinated correctly.) 591 If parallel HPR/IP links between ports are supported, multiple defined 592 link stations may be associated with the port on the adjacent node. In 593 that case, predefined TG numbers (see "Partitioning the TG Number Space" 594 in Chapter 9 Configuration Services of �1�) may be used to map the XID 595 to a specific link station. However, because the same TG 596 characteristics may be used for all HPR/IP links between a given pair of 597 ports, all the link stations associated with the port in the adjacent 598 node should be equivalent; as a result, TG number negotiation using 599 negotiable TG numbers may be used. 601 Dudley Informational �Page 11� 602 In the future, if multiple HPR/IP links with different characteristics 603 are defined between a pair of ports using RSVP, defined link stations 604 will need sufficient configured information to be matched with incoming 605 XIDs. (Correct matching of an incoming XID to a defined link station 606 allows CS to provide the correct TG characteristics to topology and 607 routing services (TRS).) At that time CS will do the mapping based on 608 both the IP address of the adjacent node and a predefined TG number. 610 The node initiating link activation knows which link it is activating. 611 Some parameters sent in prenegotiation XID are defined in the regular 612 link station configuration and not allowed to change in following 613 negotiation-proceeding XIDs. To allow for forward migration to RSVP, 614 when a regular TG is activated in an IP network, the node receiving the 615 first XID (i.e., the node not initiating link activation) must also 616 understand which defined link station is being activated before sending 617 a prenegotiation XID in order to correctly set parameters that cannot 618 change. For this reason, the node initiating link activation will 619 indicate the TG number in prenegotiation XIDs by including a TG 620 Descriptor (X'46') control vector containing a TG Identifier (X'80') 621 subfield. Furthermore, the node receiving the first XID will force the 622 node activating the link to send the first prenegotiation XID by 623 responding to null XIDs with null XIDs. To prevent potential deadlocks, 624 the node receiving the first XID has a limit (the LDLC retry count can 625 be used) on the number of null XIDs it will send. Once this limit is 626 reached, that node will send an XID with an XID Negotiation Error 627 (X'22') control vector in response to a null XID; sense data X'0809003A' 628 is included in the control vector to indicate unexpected null XID. If 629 the node that received the first XID receives a prenegotiation XID 630 without the TG Identifier subfield, it will send an XID with an XID 631 Negotiation Error control vector to reject the link connection; sense 632 data X'088C4680' is included in the control vector to indicate the 633 subfield was missing. 635 For a regular TG, the TG parameters are provided by the node operator 636 based on customer configuration in DEFINE_PORT(RQ) and DEFINE_LS(RQ). 637 The following parameters are supplied in DEFINE_LS(RQ) for HPR/IP links: 639 o The destination IP host name (this parameter can usually be mapped 640 to the destination IP address): If the link is not activated at 641 node initialization, the IP host name should be mapped to an IP 642 address, and the IP address should be stored with the link station 643 definition. This is required to allow an incoming link activation 644 to be matched with the link station definition. If the adjacent 645 node activates the link with a different IP address (e.g., it could 646 have multiple ports), it will not be possible to match the link 647 activation with the link station definition, and the default 648 parameters specified in the local port definition will be used. 650 o The destination IP version (set to version 4, support for version 6 651 may be required in the future; this parameter is only required if 652 the address and version cannot be determined using the destination 653 IP host name.) 655 Dudley Informational �Page 12� 656 o The destination IP address (in the format specified by the 657 destination IP version; this parameter is only required if the 658 address cannot be determined using the destination IP host name.) 660 o Source service access point address (SSAP) used for XID, TEST, DISC, 661 and DM (default is X'04'; other values may be specified when 662 multiple links between a pair of IP addresses are defined) 664 o Destination service access point address (DSAP) used for XID, TEST, 665 DISC, and DM (default is X'04') 667 o Source service access point address (SSAP) used for HPR network 668 layer packets (NLPs) (default is X'C8'; other values may be 669 specified when multiple links between a pair of IP addresses are 670 defined.) 672 o Maximum receive BTU size (default is 1469; this parameter is used to 673 override the setting in DEFINE_PORT.) 675 o Maximum send BTU size (default is 1469; this parameter is used to 676 override the setting in DEFINE_PORT.) 678 o IP precedence (the setting of the 3-bit field within the Type of 679 Service byte of the IP header for LLC commands such as XID and for 680 each of the APPN transmission priorities; the defaults are given in 681 2.6.1, "IP Prioritization" on page 24; this parameter is used to 682 override the settings in DEFINE_PORT) 684 o Shareable with connection network traffic (default is yes for 685 non-RSVP links) 687 o Retry count for LDLC (default is 3; this parameter is used to 688 override the setting in DEFINE_PORT) 690 o Retry timer period for LDLC (default is 15 seconds; a smaller value 691 such as 10 seconds can be used for a campus link; this parameter is 692 used to override the setting in DEFINE_PORT) 694 o LDLC liveness timer period (default is 10 seconds; this parameter is 695 used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC 696 Liveness" on page 7) 698 o Auto-activation supported (default is no; may be set to yes when the 699 local node has switched access to the IP network) 701 o Limited resource (default is to set in concert with auto-activation 702 supported) 704 o Limited resource liveness timer (default is 45 sec.) 706 o Port name 708 o Adjacent CP name (optional) 710 Dudley Informational �Page 13� 711 o Local CP-CP sessions supported 713 o Defined TG number (optional) 715 o TG characteristics 717 The following figures show the activation and deactivation of regular 718 TGs. 720 *------------------------------------------------------------------* 721 �CS DLC LDLC DMUX UDP� 722 *------------------------------------------------------------------* 723 . . . . 724 .CONNECT_OUT(RQ) . create . . 725 o--------------->o-------------->o . . 726 . � new LDLC . . 727 . o----------------------------->o . 728 CONNECT_OUT(+RSP)� . . . 729 o<---------------* . . . 730 � XID . XID(CMD) . XID 731 *------------------------------->o----------------------------->o-----> 733 Figure 3. Regular TG Activation (outgoing) 735 In Figure 3 upon receiving START_LS(RQ) from NOF, CS starts the link 736 activation process by sending CONNECT_OUT(RQ) to the DLC manager. The 737 DLC manager creates an instance of LDLC for the link, informs the link 738 demultiplexor, and sends CONNECT_OUT(+RSP) to CS. Then, CS starts the 739 activation XID exchange. 741 *------------------------------------------------------------------* 742 �CS DLC LDLC DMUX UDP� 743 *------------------------------------------------------------------* 744 . . . . 745 . CONNECT_IN(RQ) . XID(CMD) . XID . XID 746 o<---------------o<-----------------------------o<--------------o<----- 747 � CONNECT_IN(RSP). create . . 748 *--------------->o-------------->o . . 749 . � new LDLC . . 750 . o----------------------------->o . 751 . � XID(CMD) . . . 752 . *-------------->o . . 753 . XID � . . 754 o<-------------------------------* . . 755 � XID . XID(RSP) . XID 756 *------------------------------->o----------------------------->o-----> 758 Figure 4. Regular TG Activation (incoming) 760 In Figure 4, when an XID is received for a new link, it is passed to the 761 DLC manager. The DLC manager sends CONNECT_IN(RQ) to notify CS of the 762 incoming link activation, and CS sends CONNECT_IN(+RSP) accepting the 763 link activation. The DLC manager then creates a new instance of LDLC, 765 Dudley Informational �Page 14� 766 informs the link demultiplexor, and forwards the XID to to CS via LDLC. 767 CS then responds by sending an XID to the adjacent node. 769 The two following figures show normal TG deactivation (outgoing and 770 incoming). 772 *------------------------------------------------------------------* 773 �CS DLC LDLC DMUX UDP� 774 *------------------------------------------------------------------* 775 . . . . . 776 . DEACT . DISC . DISC 777 o------------------------------->o----------------------------->o-----> 778 . DEACT . DM . DM . DM 779 o<-------------------------------o<-------------o<--------------o<----- 780 � DISCONNECT(RQ) . destroy . . . 781 *--------------->o-------------->o . . 782 DISCONNECT(RSP) � . . 783 o<---------------* . . 785 Figure 5. Regular TG Deactivation (outgoing) 787 In Figure 5 upon receiving STOP_LS(RQ) from NOF, CS sends DEACT to 788 notify the partner node that the HPR link is being deactivated. When 789 the response is received, CS sends DISCONNECT(RQ) to the DLC manager, 790 and the DLC manager deactivates the instance of LDLC. Upon receiving 791 DISCONNECT(RSP), CS sends STOP_LS(RSP) to NOF. 793 *------------------------------------------------------------------* 794 �CS DLC LDLC DMUX UDP� 795 *------------------------------------------------------------------* 796 . . . . . 797 . DEACT . DISC . DISC . DISC 798 o<-------------------------------o<-------------o<--------------o<----- 799 � . � DM . DM 800 � . *----------------------------->o-----> 801 � DISCONNECT(RQ) . destroy . . . 802 *--------------->o-------------->o . . 803 .DISCONNECT(RSP) � . . 804 o<---------------* . . 806 Figure 6. Regular TG Deactivation (incoming) 808 In Figure 6, when an adjacent node deactivates a TG, the local node 809 receives a DISC. CS sends STOP_LS(IND) to NOF. Because IP is 810 connectionless, the DLC manager is not aware that the link has been 811 deactivated. For that reason, CS also needs to send DISCONNECT(RQ) to 812 the DLC manager; the DLC manager deactivates the instance of LDLC. 814 2.5.1.1 Limited Resources and Auto-Activation 816 To reduce tariff charges, the APPN architecture supports the definition 817 of switched links as limited resources. A limited-resource link is 818 deactivated when there are no sessions traversing the link. 819 Intermediate HPR nodes are not aware of sessions between logical units 821 Dudley Informational �Page 15� 822 (referred to as LU-LU sessions) carried in crossing RTP connections; in 823 HPR nodes, limited-resource TGs are deactivated when no traffic is 824 detected for some period of time. Furthermore, APPN links may be 825 defined as auto-activatable. Auto-activatable links are activated when 826 a new session has been routed across the link. 828 An HPR node may have access to an IP network via a switched access link. 829 In such environments, it may be advisable for customers to define 830 regular HPR/IP links as limited resources and as being auto-activatable. 832 2.5.2 IP Connection Networks 834 Connection network support for IP networks (option set 2010), is 835 described in this section. 837 APPN architecture defines single link TGs across the point-to-point 838 lines connecting APPN nodes. The natural extension of this model would 839 be to define a TG between each pair of nodes connected to a shared 840 access transport facility (SATF) such as a LAN or IP network. However, 841 the high cost of the system definition of such a mesh of TGs is 842 prohibitive for a network of more than a few nodes. For that reason, 843 the APPN connection network model was devised to reduce the system 844 definition required to establish TGs between APPN nodes. 846 Other TGs may be defined through the SATF which are not part of the 847 connection network. Such TGs (referred to as regular TGs in this 848 document) are required for sessions between control points (referred to 849 as CP-CP sessions) but may also be used for LU-LU sessions. 851 In the connection network model, a virtual routing node (VRN) is defined 852 to represent the SATF. Each node attached to the SATF defines a single 853 TG to the VRN rather than TGs to all other attached nodes. 855 Topology and routing services (TRS) specifies that a session is to be 856 routed between two nodes across a connection network by including the 857 connection network TGs between each of those nodes and the VRN in the 858 Route Selection control vector (RSCV). When a network node has a TG to 859 a VRN, the network topology information associated with that TG includes 860 DLC signaling information required to establish connectivity to that 861 node across the SATF. For an end node, the DLC signaling information is 862 returned as part of the normal directory services (DS) process. TRS 863 includes the DLC signaling information for TGs across connection 864 networks in RSCVs. 866 CS creates a dynamic link station when the next hop in the RSCV of an 867 ACTIVATE_ROUTE signal received from session services (SS) is a 868 connection network TG or when an adjacent node initiates link activation 869 upon receiving such an ACTIVATE_ROUTE signal. Dynamic link stations are 870 normally treated as limited resources, which means they are deactivated 871 when no sessions are using them. CP-CP sessions are not supported on 872 connections using dynamic link stations because CP-CP sessions normally 873 need to be kept up continuously. 875 Dudley Informational �Page 16� 876 Establishment of a link across a connection network normally requires 877 the use of CP-CP sessions to determine the destination IP address. 878 Because CP-CP sessions must flow across regular TGs, the definition of a 879 connection network does not eliminate the need to define regular TGs as 880 well. 882 Normally, one connection network is defined on a LAN (i.e., one VRN is 883 defined.) For an environment with several interconnected campus IP 884 networks, a single wide-area connection network can be defined; in 885 addition, separate connection networks can be defined between the nodes 886 connected to each campus IP network. 888 2.5.2.1 Establishing IP Connection Networks 890 Once the port is defined, a connection network can be defined on the 891 port. In order to support multiple TGs from a port to a VRN, the 892 connection network is defined by the following process: 894 1. A connection network and its associated VRN are defined on the port. 895 This is accomplished by the node operator issuing a 896 DEFINE_CONNECTION_NETWORK(RQ) command to NOF and NOF passing a 897 DEFINE_CN(RQ) signal to CS. 899 2. Each TG from the port to the VRN is defined by the node operator 900 issuing DEFINE_CONNECTION_NETWORK_TG(RQ) to NOF and NOF passing 901 DEFINE_CN_TG(RQ) to CS. 903 Prior to implementation of Resource ReSerVation Protocol (RSVP) support, 904 only one connection network TG between a port and a VRN is required. In 905 that case, product support for the DEFINE_CN_TG(RQ) signal is not 906 required because a single set of port configuration parameters for each 907 connection network is sufficient. If a NOF implementation does not 908 support DEFINE_CN_TG(RQ), the parameters listed in the following section 909 for DEFINE_CN_TG(RQ), are provided by DEFINE_CN(RQ) instead. 910 Furthermore, the Connection Network TG Numbers (X'81') subfield in the 911 TG Descriptor (X'46') control vector on an activation XID is only 912 required to support multiple connection network TGs to a VRN, and its 913 use is optional. 915 *-----------------------------------------------------* 916 � NO NOF CS � 917 *-----------------------------------------------------* 918 DEFINE_CONNECTION_NETWORK(RQ) DEFINE_CN(RQ) . 919 o------------------------>o----------------->o 920 DEFINE_CONNECTION_NETWORK(RSP) DEFINE_CN(RSP) � 921 o<------------------------o<-----------------* 922 DEFINE_CONNECTION_NETWORK_TG(RQ) DEFINE_CN_TG(RQ) . 923 o------------------------>o----------------->o 924 DEFINE_CONNECTION_NETWORK_TG(RSP) DEFINE_CN_TG(RSP)� 925 o<------------------------o<-----------------* 927 Figure 7. IP Connection Network Definition 929 Dudley Informational �Page 17� 930 An incoming dynamic link activation may be rejected with sense data 931 X'10160046' if there is an existing dynamic link between the two ports 932 over the same connection network (i.e., with the same VRN CP name). If 933 a node receives an activation XID for a dynamic link with an IP address 934 pair, a SAP pair, and a VRN CP name that are the same as for an active 935 dynamic link, that node can assume that the link has failed and that the 936 partner node is reactivating the link. In such a case as an 937 optimization, the node receiving the XID can take down the active link 938 and allow the link to be reestablished in the IP network. Because UDP 939 packets can arrive out of order, implementation of this optimization 940 requires the use of a timer to prevent a stray XID from deactivating an 941 active link. 943 Once all the connection networks are defined, the node operator issues 944 START_PORT(RQ), NOF passes the associated signal to CS, and CS passes 945 ACTIVATE_PORT(RQ) to the DLC manager. Upon receiving the 946 ACTIVATE_PORT(RSP) signal from the DLC manager, CS sends a TG_UPDATE 947 signal to TRS for each defined connection network TG. Each signal 948 notifies TRS that a TG to the VRN has been activated and includes TG 949 vectors describing the TG. If the port fails or is deactivated, CS 950 sends TG_UPDATE indicating the connection network TGs are no longer 951 operational. Information about TGs between a network node and the VRN 952 is maintained in the network topology database. Information about TGs 953 between an end node and the VRN is maintained only in the local topology 954 database. If TRS has no node entry in its topology database for the 955 VRN, TRS dynamically creates such an entry. A VRN node entry will 956 become part of the network topology database only if a network node has 957 defined a TG to the VRN; however, TRS is capable of selecting a direct 958 path between two end nodes across a connection network without a VRN 959 node entry. 961 *--------------------------------------------------------------------* 962 � CS TRS DLC DMUX � 963 *--------------------------------------------------------------------* 964 . ACTIVATE_PORT(RQ) . create 965 o--------------------------------------->o----------------->o 966 . ACTIVATE_PORT(RSP) � . 967 o<---------------------------------------* . 968 � TG_UPDATE . . . 969 *------------------->o . . 970 . . . . 972 Figure 8. IP Connection Network Establishment 974 The TG vectors for IP connection network TGs include the following 975 information: 977 o TG number 979 o VRN CP name 981 o TG characteristics used during route selection 983 - Effective capacity 985 Dudley Informational �Page 18� 986 - Cost per connect time 987 - Cost per byte transmitted 988 - Security 989 - Propagation delay 990 - User defined parameters 992 o Signaling information 994 - IP version (indicates the format of the IP header including the 995 IP address) 997 - IP address 999 - Link service access point address (LSAP) used for XID, TEST, 1000 DISC, and DM 1002 2.5.2.2 IP Connection Network Parameters 1004 For a connection network TG, the parameters are determined by CS using 1005 several inputs. Parameters that are particular to the local port, 1006 connection network, or TG are system defined and received in 1007 DEFINE_PORT(RQ), DEFINE_CN(RQ), or DEFINE_CN_TG(RQ). Signaling 1008 information for the destination node including its IP address is 1009 received in the ACTIVATE_ROUTE request from SS. 1011 The following configuration parameters are received in DEFINE_CN(RQ): 1013 o Connection network name (CP name of the VRN) 1015 o Limited resource liveness timer (default is 45 sec.) 1017 o IP precedence (the setting of the 3-bit field within the Type of 1018 Service byte of the IP header for LLC commands such as XID and for 1019 each of the APPN transmission priorities; the defaults are given in 1020 2.6.1, "IP Prioritization" on page 24; this parameter is used to 1021 override the settings in DEFINE_PORT) 1023 The following configuration parameters are received in DEFINE_CN_TG(RQ): 1025 o Port name 1027 o Connection network name (CP name of the VRN) 1029 o Connection network TG number (set to a value between 1 and 239) 1031 o TG characteristics (see 2.6.3, "Default TG Characteristics" on 1032 page 26) 1034 o Link service access point address (LSAP) used for XID, TEST, DISC, 1035 and DM (default is X'04') 1037 o Link service access point address (LSAP) used for HPR network layer 1038 packets (default is X'C8') 1040 Dudley Informational �Page 19� 1041 o Limited resource (default is yes) 1043 o Retry count for LDLC (default is 3; this parameter is used to 1044 override the setting in DEFINE_PORT) 1046 o Retry timer period for LDLC (default is 15 sec.; a smaller value 1047 such as 10 seconds can be used for a campus connection network; this 1048 parameter is used to override the setting in DEFINE_PORT) 1050 o LDLC liveness timer period (default is 10 seconds; this parameter is 1051 used to override the setting in DEFINE_PORT; see 2.3.1, "LDLC 1052 Liveness" on page 7) 1054 o Shareable with other HPR traffic (default is yes for non-RSVP links) 1056 o Maximum receive BTU size (default is 1469; this parameter is used to 1057 override the value in DEFINE_PORT(RQ).) 1059 o Maximum send BTU size (default is 1469; this parameter is used to 1060 override the value in DEFINE_PORT(RQ).) 1062 The following parameters are received in ACTIVATE_ROUTE for connection 1063 network TGs: 1065 o The TG pair 1067 o The destination IP version (if this version is not supported by the 1068 local node, the ACTIVATE_ROUTE_RSP reports the activation failure 1069 with sense data X'086B46A5'.) 1071 o The destination IP address (in the format specified by the 1072 destination IP version) 1074 o Destination service access point address (DSAP) used for XID, TEST, 1075 DISC, and DM 1077 2.5.2.3 Sharing of TGs 1079 Connection network traffic is multiplexed onto a regular defined IP TG 1080 (usually used for CP-CP session traffic) in order to reduce the control 1081 block storage. No XIDs flow to establish a new TG on the IP network, 1082 and no new LLC is created. When a regular TG is shared, incoming 1083 traffic is demultiplexed using the normal means. If the regular TG is 1084 deactivated, a path switch is required for the HPR connection network 1085 traffic sharing the TG. 1087 Multiplexing is possible if the following conditions hold: 1089 1. Both the regular TG and the connection network TG to the VRN are 1090 defined as shareable between HPR traffic streams. 1092 2. The destination IP address is the same. 1094 Dudley Informational �Page 20� 1095 3. The regular TG is established first. (Because links established for 1096 connection network traffic do not support CP-CP sessions, there is 1097 little value in allowing a regular TG to share such a link.) 1099 The destination node is notified via XID when a TG can be shared between 1100 HPR data streams. At either end, upon receiving ACTIVATE_ROUTE 1101 requesting a shared TG for connection network traffic, CS checks its TGs 1102 for one meeting the required specifications before initiating a new 1103 link. First, CS looks for a link established for the TG pair; if there 1104 is no such link, CS determines if there is a regular TG that can be 1105 shared and, if multiple such TGs exist, which TG to choose. As a 1106 result, RTP connections routed over the same TG pair may actually use 1107 different links, and RTP connections routed over different TG pairs may 1108 use the same link. 1110 2.5.2.4 Minimizing RSCV Length 1112 The maximum length of a Route Selection (X'2B') control vector (RSCV) is 1113 255 bytes. Use of connection networks significantly increases the size 1114 of the RSCV contents required to describe a "hop" across an SATF. 1115 First, because two connection network TGs are used to specify an SATF 1116 hop, two TG Descriptor (X'46') control vectors are required. 1117 Furthermore, inclusion of DLC signaling information within the TG 1118 Descriptor control vectors increases the length of these control 1119 vectors. As a result, the total number of hops that can be specified in 1120 RSCVs traversing connection networks is reduced. 1122 To avoid unnecessarily limiting the number of hops, a primary goal in 1123 designing the formats for IP signaling information is to minimize their 1124 size. Additional techniques are also used to reduce the effect of the 1125 RSCV length limitation. 1127 For an IP connection network, DLC signaling information is required only 1128 for the second TG (i.e., from the VRN to the destination node); the 1129 signaling information for the first TG is locally defined at the origin 1130 node. For this reason, the topology database does not include DLC 1131 signaling information for the entry describing a connection network TG 1132 from a network node to a VRN. The DLC signaling information is included 1133 in the allied entry for the TG in the opposite direction. This 1134 mechanism cannot be used for a connection network TG between a VRN and 1135 an end node. However, a node implementing IP connection networks does 1136 not include IP signaling information for the first connection network TG 1137 when constructing an RSCV. 1139 In an environment where APPN network nodes are used to route between 1140 legacy LANs and wide-area IP networks, it is recommended that customers 1141 not define connection network TGs between these network nodes and VRNs 1142 representing legacy LANs. Typically, defined links are required between 1143 end nodes on the legacy LANs and such network nodes which also act as 1144 network node servers for the end nodes. These defined links can be used 1145 for user traffic as well as control traffic. This technique will reduce 1146 the number of connection network hops in RSCVs between end nodes on 1147 different legacy LANs. 1149 Dudley Informational �Page 21� 1150 Lastly, for environments where RSCVs are still not able to include 1151 enough hops, extended border nodes (EBNs) can be used to partition the 1152 network. In this case, the EBNs will also provide piecewise subnet 1153 route calculation and RSCV swapping. Thus, the entire route does not 1154 need to be described in a single RSCV with its length limitation. 1156 2.5.3 Unsuccessful IP Link Activation 1158 Link activation may fail for several different reasons. When link 1159 activation over a connection network or of an auto-activatable link is 1160 attempted upon receiving ACTIVATE_ROUTE from SS, activation failure is 1161 reported with ACTIVATE_ROUTE_RSP containing sense data explaining the 1162 cause of failure. Likewise, when activation fails for other regular 1163 defined links, the failure is reported with START_LS(RSP) containing 1164 sense data. 1166 As is normal for session activation failures, the sense data is also 1167 sent to the node that initiated the session. At the APPN-to-HPR 1168 boundary, a -RSP(BIND) or an UNBIND with an Extended Sense Data control 1169 vector is generated and returned to the primary logical unit (PLU). 1171 At an intermediate HPR node, link activation failure can be reported 1172 with sense data X'08010000' or X'80020000'. At a node with 1173 route-selection responsibility, such failure can be reported with sense 1174 data X'80140001'. 1176 The following table contains the sense data for the various causes of 1177 link activation failure: 1179 +----------------------------------------------------------------------+ 1180 � Table 1 (Page 1 of 3). Native IP DLC Link Activation Failure Sense � 1181 � Data � 1182 +--------------------------------------------------------+-------------+ 1183 � ERROR DESCRIPTION � SENSE DATA � 1184 +--------------------------------------------------------+-------------+ 1185 � The link specified in the RSCV is not available. � X'08010000' � 1186 +--------------------------------------------------------+-------------+ 1187 � The limit for null XID responses by a called node was � X'0809003A' � 1188 � reached. � � 1189 +--------------------------------------------------------+-------------+ 1190 � A BIND was received over a subarea link, but the next � X'08400002' � 1191 � hop is over a port that supports only HPR links. The � � 1192 � receiver does not support this configuration. � � 1193 +--------------------------------------------------------+-------------+ 1194 � The contents of the DLC Signaling Type (X'91') � X'086B4691' � 1195 � subfield of the TG Descriptor (X'46') control vector � � 1196 � contained in the RSCV were invalid. � � 1197 +--------------------------------------------------------+-------------+ 1198 � The contents of the IP Address and Link Service Access � X'086B46A5' � 1199 � Point Address (X'A5') subfield of the TG Descriptor � � 1200 � (X'46') control vector contained in the RSCV were � � 1201 � invalid. � � 1202 +--------------------------------------------------------+-------------+ 1204 Dudley Informational �Page 22� 1205 +----------------------------------------------------------------------+ 1206 � Table 1 (Page 2 of 3). Native IP DLC Link Activation Failure Sense � 1207 � Data � 1208 +--------------------------------------------------------+-------------+ 1209 � ERROR DESCRIPTION � SENSE DATA � 1210 +--------------------------------------------------------+-------------+ 1211 � No DLC Signaling Type (X'91') subfield was found in � X'086D4691' � 1212 � the TG Descriptor (X'46') control vector contained in � � 1213 � the RSCV. � � 1214 +--------------------------------------------------------+-------------+ 1215 � No IP Address and Link Service Access Point Address � X'086D46A5' � 1216 � (X'A5') subfield was found in the TG Descriptor � � 1217 � (X'46') control vector contained in the RSCV. � � 1218 +--------------------------------------------------------+-------------+ 1219 � Multiple sets of DLC signaling information were found � X'08770019' � 1220 � in the TG Descriptor (X'46') control vector contained � � 1221 � in the RSCV. IP supports only one set of DLC � � 1222 � signaling information. � � 1223 +--------------------------------------------------------+-------------+ 1224 � Link Definition Error: A link is defined as not � X'08770026' � 1225 � supporting HPR, but the port only supports HPR links. � � 1226 +--------------------------------------------------------+-------------+ 1227 � A called node found no TG Identifier (X'80') subfield � X'088C4680' � 1228 � within a TG Descriptor (X'46') control vector in a � � 1229 � prenegotiation XID for a defined link in an IP � � 1230 � network. � � 1231 +--------------------------------------------------------+-------------+ 1232 � The XID3 received from the adjacent node does not � X'10160031' � 1233 � contain an HPR Capabilities (X'61') control vector. � � 1234 � The IP port supports only HPR links. � � 1235 +--------------------------------------------------------+-------------+ 1236 � The RTP Supported indicator is set to 0 in the HPR � X'10160032' � 1237 � Capabilities (X'61') control vector of the XID3 � � 1238 � received from the adjacent node. The IP port supports � � 1239 � only links to nodes that support RTP. � � 1240 +--------------------------------------------------------+-------------+ 1241 � The Control Flows over RTP Supported indicator is set � X'10160033' � 1242 � to 0 in the HPR Capabilities (X'61') control vector of � � 1243 � the XID3 received from the adjacent node. The IP port � � 1244 � supports only links to nodes that support control � � 1245 � flows over RTP. � � 1246 +--------------------------------------------------------+-------------+ 1247 � The LDLC Supported indicator is set to 0 in the HPR � X'10160034' � 1248 � Capabilities (X'61') control vector of the XID3 � � 1249 � received from the adjacent node. The IP port supports � � 1250 � only links to nodes that support LDLC. � � 1251 +--------------------------------------------------------+-------------+ 1252 � The HPR Capabilities (X'61') control vector received � X'10160044' � 1253 � in XID3 does not include an IEEE 802.2 LLC (X'80') HPR � � 1254 � Capabilities subfield. The subfield is required on an � � 1255 � IP link. � � 1256 +--------------------------------------------------------+-------------+ 1258 Dudley Informational �Page 23� 1259 +----------------------------------------------------------------------+ 1260 � Table 1 (Page 3 of 3). Native IP DLC Link Activation Failure Sense � 1261 � Data � 1262 +--------------------------------------------------------+-------------+ 1263 � ERROR DESCRIPTION � SENSE DATA � 1264 +--------------------------------------------------------+-------------+ 1265 � Multiple defined links between a pair of switched � X'10160045' � 1266 � ports is not supported by the local node. A link � � 1267 � activation request was received for a defined link, � � 1268 � but there is an active defined link between the paired � � 1269 � switched ports. � � 1270 +--------------------------------------------------------+-------------+ 1271 � Multiple dynamic links across a connection network � X'10160046' � 1272 � between a pair of switched ports is not supported by � � 1273 � the local node. A link activation request was � � 1274 � received for a dynamic link, but there is an active � � 1275 � dynamic link between the paired switched ports across � � 1276 � the same connection network. � � 1277 +--------------------------------------------------------+-------------+ 1278 � Link failure � X'80020000' � 1279 +--------------------------------------------------------+-------------+ 1280 � Route selection services has determined that no path � X'80140001' � 1281 � to the destination node exists for the specified COS. � � 1282 +--------------------------------------------------------+-------------+ 1284 2.6 IP Throughput Characteristics 1286 2.6.1 IP Prioritization 1288 Typically, IP routers process packets on a first-come-first-served 1289 basis; i.e., no packets are given transmission priority. However, some 1290 IP routers prioritize packets based on IP precedence (the 3-bit field 1291 within the Type of Service byte of the IP header) or UDP port numbers. 1292 (With the current plans for IP security, the UDP port numbers are 1293 encrypted; as a result, IP routers would not be able to prioritize 1294 encrypted traffic based on the UDP port numbers.) HPR will be able to 1295 exploit routers that provide priority function. 1297 The 5 UDP port numbers, 12000-12004 (decimal), have been assigned by the 1298 Internet Assigned Number Authority (IANA). Four of these port numbers 1299 are used for ANR-routed network layer packets (NLPs) and correspond to 1300 the APPN transmission priorities (network, 12001; high, 12002; medium, 1301 12003; and low, 12004), and one port number (12000) is used for a set of 1302 LLC commands (i.e., XID, TEST, DISC, and DM) and function-routed NLPs 1303 (i.e., XID_DONE_RQ and XID_DONE_RSP). These port numbers are used for 1304 "listening" and are also used in the destination port number field of 1305 the UDP header of transmitted packets. The source port number field of 1306 the UDP header can be set either to one of these port numbers or to an 1307 ephemeral port number. 1309 The IP precedence for each transmission priority and for the set of LLC 1310 commands (including function-routed NLPs) are configurable. The 1311 implicit assumption is that the precedence value is associated with 1312 priority queueing and not with bandwidth allocation; however, bandwidth 1314 Dudley Informational �Page 24� 1315 allocation policies can be administered by matching on the precedence 1316 field. The default mapping to IP precedence is shown in the following 1317 table: 1319 +---------------------------------------------+ 1320 � Table 2. Default IP Precedence Settings � 1321 +----------------------+----------------------+ 1322 � PRIORITY � PRECEDENCE � 1323 +----------------------+----------------------+ 1324 � Network (LLC � 110 � 1325 � commands and � � 1326 � function-routed � � 1327 � NLPs) � � 1328 +----------------------+----------------------+ 1329 � High � 100 � 1330 +----------------------+----------------------+ 1331 � Medium � 010 � 1332 +----------------------+----------------------+ 1333 � Low � 001 � 1334 +----------------------+----------------------+ 1336 As an example, with this default mapping, telnet, interactive ftp, and 1337 business-use web traffic could be mapped to a precedence value of 011, 1338 and batch ftp could be mapped to a value of 000. 1340 These settings were devised based on the AIW's understanding of the 1341 intended use of IP precedence. The use of IP precedence will be 1342 modified appropriately if the IETF standardizes its use differently. 1343 The other fields in the IP TOS byte are not used and should be set to 0. 1345 For outgoing ANR-routed NLPs, the destination (and optionally the 1346 source) UDP port numbers and IP precedence are set based on the 1347 transmission priority specified in the HPR network header. 1349 It is expected that the native IP DLC architecture described in this 1350 document will be used primarily for private campus or wide-area 1351 intranets where the customer will be able to configure the routers to 1352 honor the transmission priority associated with the UDP port numbers or 1353 IP precedence. The architecture can be used to route HPR traffic in the 1354 Internet; however, in that environment, routers do not currently provide 1355 the priority function, and customers may find the performance 1356 unacceptable. 1358 In the future, a form of bandwidth reservation may be possible in IP 1359 networks using the Resource ReSerVation Protocol (RSVP), or the 1360 differentiated services currently being studied by the Integrated 1361 Services working group of the IETF. Bandwidth could be reserved for an 1362 HPR/IP link thus insulating the HPR traffic from congestion associated 1363 with the traffic of other protocols. 1365 2.6.2 APPN Transmission Priority and COS 1367 APPN transmission priority and class of service (COS) allow APPN TGs to 1368 be highly utilized with batch traffic without impacting the performance 1370 Dudley Informational �Page 25� 1371 of response-time sensitive interactive traffic. Furthermore, scheduling 1372 algorithms guarantee that lower-priority traffic is not completely 1373 blocked. The result is predictable performance. 1375 When a session is initiated across an APPN network, the session's mode 1376 is mapped into a COS and transmission priority. For each COS, APPN has 1377 a COS table that is used in the route selection process to select the 1378 most appropriate TGs (based on their TG characteristics) for the session 1379 to traverse. The TG characteristics and COS tables are defined such 1380 that APPN topology and routing services (TRS) will select the 1381 appropriate TG for the traffic of each COS. 1383 2.6.3 Default TG Characteristics 1385 In Chapter 7 (TRS) of �1�, there is a set of SNA-defined TG default 1386 profiles. When a TG (connection network or regular) is defined as being 1387 of a particular technology (e.g., ethernet or X.25) without 1388 specification of the TG's characteristics, parameters from the 1389 technology's default profile are used in the TG's topology entry. The 1390 customer is free to override these values via configuration. Some 1391 technologies have multiple profiles (e.g., ISDN has both a profile for 1392 switched and nonswitched.) Two default profiles are required for IP 1393 TGs. This many are needed because there are both campus and wide-area 1394 IP networks. As a result for each HPR/IP TG, a customer should specify, 1395 at minimum, campus or wide area. HPR/IP TGs traversing the Internet 1396 should be specified as wide-area links. If no specification is made, a 1397 campus network is assumed. 1399 The 2 IP profiles are as follows: 1401 +----------------------------------------------------------------------+ 1402 � Table 3. IP Default TG Characteristics � 1403 +-------------------+---------+----------+---------+---------+---------+ 1404 � � Cost � Cost per � Security� Propa- � Effec- � 1405 � � per � byte � � gation � tive � 1406 � � connect � � � delay � capacity� 1407 � � time � � � � � 1408 +-------------------+---------+----------+---------+---------+---------+ 1409 � Campus � 0 � 0 � X'01' � X'71' � X'75' � 1410 +-------------------+---------+----------+---------+---------+---------+ 1411 � Wide area � 0 � 0 � X'20' � X'91' � X'44' � 1412 +-------------------+---------+----------+---------+---------+---------+ 1414 Typically, a TG is either considered to be "free" if it is owned or 1415 leased or "costly" if it is a switched carrier facility. Free TGs have 1416 0 for both cost parameters, and costly TGs have 128 for both parameters. 1417 For campus IP networks, the default for both cost parameters is 0. 1419 It is less clear what the defaults should be for wide area. Because a 1420 router normally has leased access to an IP network, the defaults for 1421 both costs are also 0. This assumes the IP network is not tariffed. 1422 However, if the IP network is tariffed, then the customer should set the 1423 cost per byte to 0 or 128 depending on whether the tariff contains a 1424 component based on quantity of data transmitted, and the customer should 1426 Dudley Informational �Page 26� 1427 set the cost per connect time to 0 or 128 based on whether there is a 1428 tariff component based on connect time. Furthermore, for switched 1429 access to the IP network, the customer settings for both costs should 1430 also reflect the tariff associated with the switched access link. 1432 Only architected values (see "Security" in �1�) may be used for a TG's 1433 security parameter. The default security value is X'01' (lowest) for 1434 campus and X'20' (public switched network; secure in the sense that 1435 there is no predetermined route the traffic will take) for wide-area IP 1436 networks. The network administrator may override the default value but 1437 should, in that case, ensure that an appropriate level of security 1438 exists. 1440 For wide area, the value X'91' (packet switched) is the default for 1441 propagation delay; this is consistent with other wide-area facilities 1442 and indicates that IP packets will experience both terrestrial 1443 propagation delay and queueing delay in intermediate routers. This 1444 value is suitable for both the Internet and wide-area intranets; 1445 however, the customer could use different values to favor intranets over 1446 the Internet during route selection. The value X'99' (long) may be 1447 appropriate for some international links across the Internet. For 1448 campus, the default is X'71' (terrestrial); this setting essentially 1449 equates the queueing delay in IP networks with terrestrial propagation 1450 delay. 1452 For wide area, X'44' (56 kbs) is shown as the default effective 1453 capacity; this is at the low-end of typical speeds for wide-area IP 1454 links. For campus, X'75' (4 Mbs) is the default; this is at the low-end 1455 of typical speeds for campus IP links. However, customers should set 1456 the effective capacity for both campus and wide area IP links based on 1457 the actual physical speed of the access link to the IP network; for 1458 regular links, if both the source and destination access speeds are 1459 known, customers should set the effective capacity based on the minimum 1460 of these two link speeds. If there are multiple access links, the 1461 capacity setting should be based on the physical speed of the access 1462 link that is expected to be used for the link. 1464 For the encoding technique for effective capacity in the topology 1465 database, see "Effective Capacity" in Chapter 7, Topology and Routing 1466 Services of �1�. The table in that section can be extended as follows 1467 for higher speeds: 1469 Dudley Informational �Page 27� 1470 +----------------------------------------------------------------------+ 1471 � Table 4. Calculated Effective Capacity Representations � 1472 +-----------------------------------+----------------------------------+ 1473 � Link Speed (Approx.) � Effective Capacity � 1474 +-----------------------------------+----------------------------------+ 1475 � 25M � X'8A' � 1476 +-----------------------------------+----------------------------------+ 1477 � 45M � X'91' � 1478 +-----------------------------------+----------------------------------+ 1479 � 100M � X'9A' � 1480 +-----------------------------------+----------------------------------+ 1481 � 155M � X'A0' � 1482 +-----------------------------------+----------------------------------+ 1483 � 467M � X'AC' � 1484 +-----------------------------------+----------------------------------+ 1485 � 622M � X'B0' � 1486 +-----------------------------------+----------------------------------+ 1487 � 1G � X'B5' � 1488 +-----------------------------------+----------------------------------+ 1489 � 1.9G � X'BC' � 1490 +-----------------------------------+----------------------------------+ 1492 2.6.4 SNA-Defined COS Tables 1494 SNA-defined batch and interactive COS tables are provided in �1�. These 1495 tables are enhanced in �2� (see section 18.7.2) for the following 1496 reasons: 1498 o To ensure that the tables assign reasonable weights to ATM TGs 1499 relative to each other and other technologies based on cost, speed, 1500 and delay 1502 o To facilitate use of other new higher-speed facilities - This goal 1503 is met by providing several speed groupings above 10 Mbps. To keep 1504 the tables from growing beyond 12 rows, low-speed groupings are 1505 merged. 1507 Products implementing the native IP DLC should use the new COS tables. 1508 Although the effective capacity values in the old tables are sufficient 1509 for typical IP speeds, the new tables are valuable because higher-speed 1510 links can be used for IP networks. 1512 2.6.5 Route Setup over HPR/IP links 1514 The Resequence ("REFIFO") indicator is set in Route Setup request and 1515 reply when the RTP path uses a multi-link TG because packets may not be 1516 received in the order sent. The Resequence indicator is also set when 1517 the RTP path includes an HPR/IP link as packets sent over an IP network 1518 may arrive out of order. 1520 Adaptive rate-based congestion control (ARB) is an HPR Rapid Transport 1521 Protocol (RTP) function that controls the data transmission rate over 1522 RTP connections. ARB also provides fairness between the RTP traffic 1523 streams sharing a link. For ARB to perform these functions in the IP 1525 Dudley Informational �Page 28� 1526 environment, it is necessary to coordinate the ARB parameters with the 1527 IP TG characteristics. This is done for IP links in a similar manner to 1528 that done for other link types. 1530 2.6.6 Access Link Queueing 1532 Typically, nodes implementing the native IP DLC have an access link to a 1533 network of IP routers. These IP routers may be providing prioritization 1534 based on UDP port numbers or IP precedence. A node implementing the 1535 native IP DLC can be either an IP host or an IP router; in both cases, 1536 such nodes should also honor the priorities associated with either the 1537 UDP port numbers or the IP precedence when transmitting HPR data over 1538 the access link to the IP network. 1540 ------------------------------------------------------------------------ 1542 *--------* access link *--------* *--------* 1543 � HPR �-------------� IP �-----� IP � 1544 � node � � Router � � Router � 1545 *--------* *--------* *--------* 1546 � � 1547 � � 1548 � � 1549 *--------* *--------* access link *--------* 1550 � IP �-----� IP �-------------� HPR � 1551 � Router � � Router � � node � 1552 *--------* *--------* *--------* 1554 ------------------------------------------------------------------------ 1555 Figure 9. Access Links 1557 Otherwise, the priority function in the router network will be negated 1558 with the result being HPR interactive traffic delayed by either HPR 1559 batch traffic or the traffic of other higher-layer protocols at the 1560 access link queues. 1562 2.7 Port Link Activation Limits 1564 Three parameters are provided by NOF to CS on DEFINE_PORT(RQ) to define 1565 the link activation limits for a port: total limit, inbound limit, and 1566 outbound limit. The total limit is the desired maximum number of active 1567 link stations allowed on the port for both regular TGs and connection 1568 network TGs. The inbound limit is the desired number of link stations 1569 reserved for connections initiated by adjacent nodes; the purpose of 1570 this field is to insure that a minimum number of link stations may be 1571 activated by adjacent nodes. The outbound limit is the desired number 1572 of link stations reserved for connections initiated by the local node. 1573 The sum of the inbound and outbound limits must be less than or equal to 1574 the total limit. If the sum is less than the total limit, the 1575 difference is the number of link stations that can be activated on a 1576 demand basis as either inbound or outbound. These limits should be 1577 based on the actual adapter capability and the node's resources (e.g., 1578 control blocks). 1580 Dudley Informational �Page 29� 1581 A connection network TG will be reported to topology as quiescing when 1582 its port's total limit threshold is reached; likewise, an inactive 1583 auto-activatable regular TG is reported as nonoperational. When the 1584 number of active link stations drops far enough below the threshold 1585 (e.g., so that at least 20 percent of the original link activation limit 1586 has been recovered), connection network TGs are reported as not 1587 quiescing, and auto-activatable TGs are reported as operational. 1589 2.8 Network Management 1591 APPN and HPR management information is defined by the APPN MIB 1592 (available as RFC 2155 �11� in one of the repositories of IETF RFCs) and 1593 the HPR MIB (available at 1594 ftp://ietf.org/internet-drafts/draft-ietf-snanau-hprmib-02.txt). In 1595 addition, the SNANAU working group of the IETF plans to define an 1596 HPR-IP-MIB that will provide HPR/IP-specific management information. In 1597 particular, this MIB will provide a mapping of APPN traffic types to IP 1598 Type of Service Precedence values, as well as a count of UDP packets 1599 sent for each traffic type. 1601 There are also rules that must be specified concerning the values an 1602 HPR/IP implementation returns for objects in the APPN MIB: 1604 o Several objects in the APPN MIB have the syntax IANAifType. The 1605 value 126, defined as "IP (for APPN HPR in IP networks)" should be 1606 returned by the following three objects when they identify an HPR/IP 1607 link: 1609 - appnPortDlcType 1610 - appnLsDlcType 1611 - appnLsStatusDlcType 1613 o Link-level addresses are reported in the following objects: 1615 - appnPortDlcLocalAddr 1616 - appnLsLocalAddr 1617 - appnLsRemoteAddr 1618 - appnLsStatusLocalAddr 1619 - appnLsStatusRemoteAddr 1621 All of these objects should return ASCII character strings that 1622 represent IP addresses in the usual dotted-decimal format. (At this 1623 point it's not clear what the "usual...format" will be for IPv6 1624 addresses, but whatever it turns out to be, that is what these 1625 objects will return when an HPR/IP link traverses an IP network.) 1627 o The following two objects return Object Identifiers that tie table 1628 entries in the APPN MIB to entries in lower-layer MIBs: 1630 - appnPortSpecific 1631 - appnLsSpecific 1633 Both of these objects should return the same value: a RowPointer to 1634 the ifEntry in the agent's ifTable for the physical interface 1636 Dudley Informational �Page 30� 1637 associated with the local IP address for the port. If the agent 1638 implements the IP-MIB (RFC 2011�12�), this association between the 1639 IP address and the physical interface will be represented in the 1640 ipNetToMediaTable. 1642 2.9 IPv4-to-IPv6 Migration 1644 The native IP DLC is architected to use IP version 4 (IPv4). However, 1645 support for IP version 6 (IPv6) may be required in the future. 1647 IP routers and hosts can interoperate only if both ends use the same 1648 version of the IP protocol. However, most IPv6 implementations (routers 1649 and hosts) will actually have dual IPv4/IPv6 stacks. IPv4 and IPv6 1650 traffic can share transmission facilities provided that the router/host 1651 at each end has a dual stack. IPv4 and IPv6 traffic will coexist on the 1652 same infrastructure in most areas. The version number in the IP header 1653 is used to map incoming packets to either the IPv4 or IPv6 stack. A 1654 dual-stack host which wishes to talk to an IPv4 host will use IPv4. 1656 Hosts which have an IPv4 address can use it as an IPv6 address using a 1657 special IPv6 address prefix (i.e., it is an embedded IPv4 address). 1658 This mapping was provided mainly for "legacy" application compatibility 1659 purposes as such applications don't have the socket structures needed to 1660 store full IPv6 addresses. Two IPv6 hosts may communicate using IPv6 1661 with embedded-IPv4 addresses. 1663 Both IPv4 and IPv6 addresses can be stored by the domain name service 1664 (DNS). When an application queries DNS, it asks for IPv4 addresses, IPv6 1665 addresses, or both. So, it's the application that decides which stack to 1666 use based on which addresses it asks for. 1668 Migration for HPR/IP ports will work as follows: 1670 An HPR/IP port is configured to support IPv4, IPv6, or both. If IPv4 is 1671 supported, a local IPv4 address is defined; if IPv6 is supported, a 1672 local IPv6 address (which can be an embedded IPv4 address) is defined. 1673 If both IPv4 and IPv6 are supported, both a local IPv4 address and a 1674 local IPv6 address are defined. 1676 Defined links will work as follows: If the local node supports IPv4 1677 only, a destination IPv4 address may be defined, or an IP host name may 1678 be defined in which case DNS will be queried for an IPv4 address. If 1679 the local node supports IPv6 only, a destination IPv6 address may be 1680 defined, or an IP host name may be defined in which case DNS will be 1681 queried for an IPv6 address. If both IPv4 and IPv6 are supported, a 1682 destination IPv4 address may be defined, a destination IPv6 address may 1683 be defined, or an IP host name may be defined in which case DNS will be 1684 queried for both IPv4 and IPv6 addresses; if provided by DNS, an IPv6 1685 address can be used, and an IPv4 address can be used otherwise. 1687 Separate IPv4 and IPv6 connection networks can be defined. If the local 1688 node supports IPv4, it can define a connection network TG to the IPv4 1689 VRN. If the local node supports IPv6, it can define a TG to the IPv6 1690 VRN. If both are supported, TGs can be defined to both VRNs. 1692 Dudley Informational �Page 31� 1693 Therefore, the signaling information received in RSCVs will be 1694 compatible with the local node's capabilities unless a configuration 1695 error has occurred. 1697 3.0 References 1699 �1� IBM, Systems Network Architecture Advanced Peer-to-Peer Networking 1700 Architecture Reference, SC30-3442-04. Viewable at URL: 1701 http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50L0000/CCONTENTS 1703 �2� IBM, Systems Network Architecture Advanced Peer-to-Peer Networking 1704 High Performance Routing Architecture Reference, Version 3.0, 1705 SV40-1018-02. Viewable at URL: 1706 http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50H6001/CCONTENTS 1708 �3� IBM, Systems Network Architecture Formats, GA27-3136-16. Viewable 1709 at URL: 1710 http://www.raleigh.ibm.com/cgi-bin/bookmgr/BOOKS/D50A5003/CCONTENTS 1712 �4� Wells, L., and A. Bartky, "Data Link Switching: Switch-to-Switch 1713 Protocol, AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1714 1.0", RFC 1795, April, 1995. 1716 �5� Bryant, D., and P. Brittain, "APPN Implementers' Workshop Closed 1717 Pages Document DLSw v2.0 Enhancements", RFC 2166, June, 1997. 1719 �6� Postel, J., "User Datagram Protocol", RFC 768, August, 1980. 1721 �7� Postel, J., "Internet Protocol", RFC 791, September, 1981. 1723 �8� Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1724 1349, July, 1992. 1726 �9� Braden, R., "Requirements for Internet Hosts -- Communication 1727 Layers", RFC 1122, October, 1989. 1729 �10� Braden, R., L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource 1730 ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", 1731 RFC 2205, September, 1997. 1733 �11� Clouston, B., and B. Moore, "Definitions of Managed Objects for 1734 APPN using SMIv2", RFC 2155, June, 1997. 1736 �12� McCloghrie, K., "SNMPv2 Management Information Base for the 1737 Internet Protocol using SMIv2", RFC 2011, November, 1996. 1739 4.0 Security Considerations 1741 Security issues are not discussed in this memo. 1743 Dudley Informational �Page 32� 1744 5.0 Author's Address 1746 Gary Dudley 1747 C3BA/501 1748 IBM Corporation 1749 P.O. Box 12195 1750 Research Triangle Park, NC 27709, USA 1752 Phone: +1 919-254-4358 1753 Fax: +1 919-254-6243 1754 EMail: dudleyg@us.ibm.com 1756 6.0 Appendix - Packet Format 1758 Dudley Informational �Page 33� 1759 6.1 HPR Use of IP Formats 1761 +----------------------------------------------------------------------+ 1762 � 6.1.1 IP Format for LLC Commands and Responses � 1763 � � 1764 � The formats described here are used for the � 1765 � following LLC commands and responses: XID � 1766 � command and response, TEST command and response, � 1767 � DISC command, and DM response. � 1768 +----------------------------------------------------------------------+ 1770 +----------------------------------------------------------------------+ 1771 � IP Format for LLC Commands and Responses � 1772 +-------+-----+--------------------------------------------------------+ 1773 � Byte � Bit � Content � 1774 +-------+-----+--------------------------------------------------------+ 1775 +-------+-----+--------------------------------------------------------+ 1776 � 0-p � � IP header (see note 1) � 1777 +-------+-----+--------------------------------------------------------+ 1778 +-------+-----+--------------------------------------------------------+ 1779 � p+1-p+� � UDP header (see note 2) � 1780 +-------+-----+--------------------------------------------------------+ 1781 +-------+-----+--------------------------------------------------------+ 1782 � p+9-p+�1 � IEEE 802.2 LLC header (see note 3) � 1783 _____________________ 1784 +-------+-----+--------------------------------------------------------+ 1785 +-------+-----+--------------------------------------------------------+ 1786 � p+9 � � DSAP: same as for the base APPN (i.e., X'04' or an � 1787 � � � installation-defined value) � 1788 +-------+-----+--------------------------------------------------------+ 1789 +-------+-----+--------------------------------------------------------+ 1790 � p+10 � � SSAP: same as for the base APPN (i.e., X'04' or an � 1791 � � � installation-defined value) � 1792 +-------+-----+--------------------------------------------------------+ 1793 +-------+-----+--------------------------------------------------------+ 1794 � p+11 � � Control: set as appropriate � 1795 +-------+-----+--------------------------------------------------------+ 1796 +-------+-----+--------------------------------------------------------+ 1797 � p+12-n� � Remainder of PDU: XID3 or TEST information field, or � 1798 � � � null for DISC command and DM response � 1799 +-------+-----+--------------------------------------------------------+ 1800 +-------+-----+--------------------------------------------------------+ 1801 � � � Note 1: Rules for encoding the IP header can be found � 1802 � � � in RFC 791. � 1803 +-------+-----+--------------------------------------------------------+ 1804 +-------+-----+--------------------------------------------------------+ 1805 � � � Note 2: Rules for encoding the UDP header can be � 1806 � � � found in RFC 768. � 1807 +-------+-----+--------------------------------------------------------+ 1809 Dudley Informational �Page 34� 1810 +----------------------------------------------------------------------+ 1811 � IP Format for LLC Commands and Responses � 1812 +-------+-----+--------------------------------------------------------+ 1813 � Byte � Bit � Content � 1814 +-------+-----+--------------------------------------------------------+ 1815 +-------+-----+--------------------------------------------------------+ 1816 � � � Note 3: Rules for encoding the IEEE 802.2 LLC header � 1817 � � � can be found in ISO/IEC 8802-2:1994 (ANSI/IEEE Std � 1818 � � � 802.2, 1994 Edition), Information technology - � 1819 � � � Telecommunications and information exchange between � 1820 � � � systems - Local and metropolitan area networks - � 1821 � � � Specific requirements - Part 2: Logical Link Control. � 1822 +-------+-----+--------------------------------------------------------+ 1824 Dudley Informational �Page 35� 1825 +----------------------------------------------------------------------+ 1826 � 6.1.2 IP Format for NLPs in UI Frames � 1827 � � 1828 � This format is used for either LDLC specific � 1829 � messages or HPR session and control traffic. � 1830 +----------------------------------------------------------------------+ 1832 +----------------------------------------------------------------------+ 1833 � IP Format for NLPs in UI Frames � 1834 +-------+-----+--------------------------------------------------------+ 1835 � Byte � Bit � Content � 1836 +-------+-----+--------------------------------------------------------+ 1837 +-------+-----+--------------------------------------------------------+ 1838 � 0-p � � IP header (see note 1) � 1839 +-------+-----+--------------------------------------------------------+ 1840 +-------+-----+--------------------------------------------------------+ 1841 � p+1-p+� � UDP header (see note 2) � 1842 +-------+-----+--------------------------------------------------------+ 1843 +-------+-----+--------------------------------------------------------+ 1844 � p+9-p+�1 � IEEE 802.2 LLC header � 1845 _____________________ 1846 +-------+-----+--------------------------------------------------------+ 1847 +-------+-----+--------------------------------------------------------+ 1848 � p+9 � � DSAP: the destination SAP obtained from the IEEE � 1849 � � � 802.2 LLC (X'80') subfield in the HPR Capabilities � 1850 � � � (X'61') control vector in the received XID3 (see note � 1851 � � � 3) � 1852 +-------+-----+--------------------------------------------------------+ 1853 +-------+-----+--------------------------------------------------------+ 1854 � p+10 � � SSAP: the source SAP obtained from the IEEE 802.2 LLC � 1855 � � � (X'80') subfield in the HPR Capabilities (X'61') � 1856 � � � control vector in the sent XID3 (see note 4) � 1857 +-------+-----+--------------------------------------------------------+ 1858 +-------+-----+--------------------------------------------------------+ 1859 � p+11 � � Control: � 1860 +-------+-----+-------+------------------------------------------------+ 1861 � � � X'03' � UI with P/F bit off � 1862 +-------+-----+-------+------------------------------------------------+ 1863 +-------+-----+--------------------------------------------------------+ 1864 � p+12-n� � Remainder of PDU: NLP � 1865 +-------+-----+--------------------------------------------------------+ 1866 +-------+-----+--------------------------------------------------------+ 1867 � � � Note 1: Rules for encoding the IP header can be found � 1868 � � � in RFC 791. � 1869 +-------+-----+--------------------------------------------------------+ 1870 +-------+-----+--------------------------------------------------------+ 1871 � � � Note 2: Rules for encoding the UDP header can be � 1872 � � � found in RFC 768. � 1873 +-------+-----+--------------------------------------------------------+ 1875 Dudley Informational �Page 36� 1876 +----------------------------------------------------------------------+ 1877 � IP Format for NLPs in UI Frames � 1878 +-------+-----+--------------------------------------------------------+ 1879 � Byte � Bit � Content � 1880 +-------+-----+--------------------------------------------------------+ 1881 +-------+-----+--------------------------------------------------------+ 1882 � � � Note 3: The User-Defined Address bit is considered � 1883 � � � part of the DSAP. The Individual/Group bit in the � 1884 � � � DSAP field is set to 0 by the sender and ignored by � 1885 � � � the receiver. � 1886 +-------+-----+--------------------------------------------------------+ 1887 +-------+-----+--------------------------------------------------------+ 1888 � � � Note 4: The User-Defined Address bit is considered � 1889 � � � part of the SSAP. The Command/Response bit in the � 1890 � � � SSAP field is set to 0 by the sender and ignored by � 1891 � � � the receiver. � 1892 +-------+-----+--------------------------------------------------------+ 1894 7.0 Full Copyright Statement 1896 Copyright (C) The Internet Society (1997). All Rights Reserved. 1898 This document and translations of it may be copied and furnished to 1899 others, and derivative works that comment on or otherwise explain it or 1900 assist in its implementation may be prepared, copied, published and 1901 distributed, in whole or in part, without restriction of any kind, 1902 provided that the above copyright notice and this paragraph are included 1903 on all such copies and derivative works. However, this document itself 1904 may not be modified in any way, such as by removing the copyright notice 1905 or references to the Internet Society or other Internet organizations, 1906 except as needed for the purpose of developing Internet standards in 1907 which case the procedures for copyrights defined in the Internet 1908 Standards process must be followed, or as required to translate it into 1909 languages other than English. 1911 The limited permissions granted above are perpetual and will not be 1912 revoked by the Internet Society or its successors or assigns. 1914 This document and the information contained herein is provided on an "AS 1915 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1916 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1917 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1918 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1919 FITNESS FOR A PARTICULAR PURPOSE. 1921 Dudley Informational �Page 37� 1922 INTERNET DRAFT EXPIRES AUGUST 1998 INTERNET DRAFT