<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 20px; font-family: Calibri, sans-serif;">
<div>Peter,</div>
<div><br>
</div>
<div>USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header.</div>
<div>Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits.</div>
<div>There is a SANA registry for PIDs under <a href="http://sanaregistry.org/r/protocol_id/protocol_id.html">http://sanaregistry.org/r/protocol_id/protocol_id.html</a></div>
<div><br>
</div>
<div>IPoC also defines PIDs as well for the IPE header. See <a href="http://sanaregistry.org/r/ipe_header/ipe_header.html">http://sanaregistry.org/r/ipe_header/ipe_header.html</a></div>
<div>In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet.</div>
<div><br>
</div>
<div>USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits.</div>
<div>Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below.</div>
<div><br>
</div>
<div>Question – What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the
 USLP links ?</div>
<div>In the review of USLP, we will address questions like, “Is a 13 bit PID name space sufficient for all agency needs ?”</div>
<div><br>
</div>
<div>Your thoughts ?</div>
<div><br>
</div>
<div>Thanks!</div>
<div>Greg</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>"Greenberg, Edward (312B)" <<a href="mailto:edward.greenberg@jpl.nasa.gov">edward.greenberg@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, February 2, 2016 at 9:53 AM<br>
<span style="font-weight:bold">To: </span>"Kazz, Greg J (313B)" <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Subject: </span>PIDs<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Encap uses 3 bits +8bits when 3bits=111</div>
<div>USLP uses 5 bits +8 bits when 5 bits =11111</div>
<div><br>
</div>
<div>Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx</div>
<div><br>
</div>
<div><br>
</div>
<div>The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10  don't map to Encap</div>
</div>
</div>
</span>
</body>
</html>